Cómo usar la API de Kling sin el proceso de incorporación directo con Kling: guía de 2026

TL;DR Puedes acceder a los modelos de video compatibles con Kling a través de CometAPI con una cuenta y clave de API de CometAPI, en lugar de completar un flujo de incorporación de desarrollador de Kling por separado. La ruta actual de texto a video es POST /kling/v1/videos/text2video. Devuelve un ID de tarea que tu backend sondea hasta que la tarea llegue a succeed o failed. La disponibilidad de modelos, los parámetros, los precios y la elegibilidad de la cuenta pueden cambiar, así que verifica el catálogo de modelos en vivo y la documentación del API antes del despliegue a producción.

Respuesta directa

La vía práctica es el catálogo de modelos de Kling de CometAPI. Si el modelo de Kling que necesitas está disponible para tu cuenta de CometAPI, tu servidor puede autenticarse con una clave de API de CometAPI y llamar al endpoint correspondiente compatible con Kling. Por esta vía, una aplicación de API de Kling por separado no forma parte de los pasos de integración.

Esta distinción importa para equipos que ya usan CometAPI para otros modelos. La aplicación mantiene una única superficie de gestión de credenciales y una sola relación con el proveedor a la vez que añade un flujo de video de Kling. Tu código aún debe usar el esquema de solicitud específico de video de Kling y su ciclo de vida de tarea asíncrono; “una clave de API” no significa que todos los proveedores compartan un mismo cuerpo de solicitud.

Este artículo se centra en texto a video porque es la integración útil más pequeña. CometAPI también documenta imagen a video y otros flujos de Kling, pero cada uno tiene su propio endpoint y restricciones de parámetros. Empieza con una vía verificada y añade capacidades solo después de revisar la documentación actual.

Por qué esta vía puede ser útil para un equipo de desarrollo

El beneficio inmediato es operativo, no mágico. Un equipo que ya usa CometAPI puede añadir un flujo de Kling disponible sin crear otra integración directa con un proveedor, distribuir otra credencial o construir una ruta separada de gestión de cuentas. Eso puede reducir el número de secretos, relaciones de facturación y configuraciones de cliente específicas de proveedor que tu plataforma debe mantener.

El segundo beneficio es arquitectónico. Tu aplicación puede exponer un pequeño contrato interno de generación de video—prompt, flujo, modelo, opciones y estado del trabajo—mientras un adaptador de proveedor traduce ese contrato en la solicitud documentada de Kling. Si el equipo evalúa más tarde otro modelo de video, el modelo de trabajo de cara al producto puede permanecer estable aunque cambien las rutas, los parámetros y los metadatos de salida.

La limitación es igual de importante: una capa de acceso consolidada no hace que los modelos subyacentes sean intercambiables. El comportamiento del prompt, los medios aceptados, la latencia, los precios, las políticas de seguridad y los esquemas de resultados pueden variar. Mantén esas diferencias visibles en la configuración y las pruebas en lugar de ocultarlas tras suposiciones no admitidas.

Qué cambia con esta vía de acceso—y qué no

Lo que cambia. Creas y gestionas una clave de CometAPI, envías solicitudes al API compatible con Kling de CometAPI y haces el seguimiento del uso desde el lado de CometAPI. Esto elimina un paso de incorporación directa a Kling de esta vía de acceso en particular.

Lo que no cambia. Kling sigue siendo la familia de modelos subyacente. Los parámetros específicos del proveedor, el comportamiento de generación, las reglas de uso aceptable, la disponibilidad del modelo y las características de salida siguen importando. La documentación de CometAPI también señala que los campos de solicitud y respuesta del proveedor pueden diferir, así que trata la referencia del endpoint en vivo como el contrato para tu implementación.

Qué deberías verificar antes de comprometerte. Confirma que tu cuenta puede acceder al ID de modelo requerido, revisa el precio y los límites de tasa actuales y ejecuta una pequeña prueba autenticada. No diseñes un flujo de producción en torno a un nombre de modelo visto en una entrada de blog antigua o en un ejemplo en caché.

Antes de empezar

Necesitas una cuenta de CometAPI, una clave de API almacenada en tu servidor y un backend capaz de ejecutar un trabajo asíncrono. Mantén la clave en una variable de entorno como COMETAPI_KEY; no la expongas en el navegador o en el código de clientes móviles.

1. Abre el catálogo de modelos de Kling y confirma que el modelo que piensas usar está listado actualmente para tu cuenta.
2. Revisa la referencia actual del API de texto a video de Kling. En el momento de la verificación, el ejemplo documentado usa kling-v3.
3. Crea una clave de API del lado servidor en la consola de CometAPI y configúrala en tu entorno de ejecución.
4. Decide dónde almacenará tu servicio el ID de la tarea y el video final. La solicitud de generación devuelve una tarea, no el archivo de video terminado.

Elige el flujo de Kling antes de diseñar la solicitud

Parte del recurso que tu producto ya tiene. Si el usuario solo tiene un concepto escrito, texto a video es la vía directa. Si el usuario tiene una imagen fija que debe permanecer como ancla visual, usa la ruta documentada por separado de imagen a video. No añadas un campo de imagen a una solicitud de texto a video asumiendo que el API inferirá el flujo.

La referencia actual de imagen a video acepta una URL pública de imagen o una cadena de imagen en base64 y devuelve una tarea asíncrona. Los flujos más especializados de Kling tienen sus propias páginas y restricciones de solicitud. Añádelos uno por uno solo cuando el requisito del producto y la documentación actual justifiquen el adaptador extra.

Para una primera prueba de producción, usa un flujo, un ID de modelo verificado, una duración corta y un pequeño conjunto de prompts representativos. Esto aísla el acceso a la cuenta y la orquestación de tareas de la evaluación subjetiva de la salida. Una vez que la canalización sea confiable, compara modos o modelos con un conjunto de evaluación fijo en lugar de cambiar varias variables en la misma prueba.

Realiza tu primera solicitud de texto a video de Kling

El endpoint actual de texto a video acepta JSON y autenticación Bearer. Comienza con un prompt corto y la duración más pequeña admitida. La siguiente solicitud usa solo los campos mostrados en la referencia actual de CometAPI:

curl https://api.cometapi.com/kling/v1/videos/text2video \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "A small ceramic cup on a wooden table, steam rising in soft morning light",
    "model_name": "kling-v3",
    "mode": "std",
    "duration": "5",
    "sound": "off"
  }'

Una presentación exitosa devuelve un objeto que contiene data.task_id y un estado de tarea. Guarda ese ID de tarea con el registro de trabajo de tu aplicación. No mantengas la conexión HTTP abierta mientras se renderiza el video.

Gestiona la tarea asíncrona de forma segura

La generación en Kling es asíncrona. Para texto a video, sondea GET /kling/v1/videos/text2video/{task_id}. La referencia de tareas de CometAPI dice que una respuesta puede devolver la tarea directamente o dentro de un envoltorio data, así que el ejemplo normaliza ambas formas. También trata todo estado no terminal como “seguir esperando”, en lugar de asumir una lista fija de estados intermedios.

import os
import time
import requests

API_KEY = os.environ["COMETAPI_KEY"]
BASE_URL = "https://api.cometapi.com/kling/v1/videos/text2video"
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}


def submit_video(prompt: str) -> str:
    response = requests.post(
        BASE_URL,
        headers=HEADERS,
        json={
            "prompt": prompt,
            "model_name": "kling-v3",
            "mode": "std",
            "duration": "5",
            "sound": "off",
        },
        timeout=30,
    )
    response.raise_for_status()
    payload = response.json()
    return payload["data"]["task_id"]


def wait_for_video(task_id: str, timeout_seconds: int = 600) -> str:
    deadline = time.monotonic() + timeout_seconds
    poll_url = f"{BASE_URL}/{task_id}"

    while time.monotonic() < deadline:
        response = requests.get(poll_url, headers=HEADERS, timeout=30)
        response.raise_for_status()
        payload = response.json()
        task = payload.get("data") or payload
        status = task.get("task_status")

        if status == "succeed":
            videos = task.get("task_result", {}).get("videos", [])
            if not videos or not videos[0].get("url"):
                raise RuntimeError("Task succeeded without a video URL")
            return videos[0]["url"]

        if status == "failed":
            detail = task.get("task_status_msg") or task.get("task_result")
            raise RuntimeError(f"Kling task failed: {detail}")

        time.sleep(10)

    raise TimeoutError(f"Kling task {task_id} exceeded {timeout_seconds}s")


task_id = submit_video(
    "A small ceramic cup on a wooden table, steam rising in soft morning light"
)
video_url = wait_for_video(task_id)
print(video_url)

La cadena de éxito terminal es succeed, no succeeded. Cuando una tarea completa, copia el recurso generado a un almacenamiento bajo tu control si tu producto requiere retención. No se deben tratar las URL de entrega del proveedor como almacenamiento permanente de la aplicación.

Para cargas de trabajo mayores, usa una cola o un worker en lugar de sondear dentro de una solicitud web. CometAPI también documenta URL de callback para tareas de Kling. Si adoptas webhooks, autentica y desduplica los eventos de callback, y conserva un sondeo de respaldo para entregas perdidas.

Diseña el ciclo de vida del trabajo de la aplicación antes de escalar

Trata la tarea del proveedor como una parte de tu propio registro de trabajo. Almacena un ID de trabajo de la aplicación, el flujo, el modelo solicitado, el ID de tarea del proveedor, la URL de consulta, el estado actual, la marca temporal de envío, la hora del último sondeo y la ubicación de salida. Esto da a tus equipos de soporte y operaciones suficiente contexto para investigar una generación fallida o lenta sin buscar en registros de solicitud en bruto.

No reintentes la solicitud de creación solo porque el cliente no recibió una respuesta. Es posible que el proveedor ya haya creado una tarea. Conserva tu trabajo local antes del envío, guarda el ID de tarea devuelto de inmediato y separa los reintentos de creación de los reintentos de consulta de estado. La referencia actual de texto a video también documenta external_task_id para seguimiento; confirma su comportamiento en vivo antes de confiar en él como mecanismo de desduplicación.

const TERMINAL = new Set(["succeed", "failed"]);

function normalizeKlingTask(payload) {
  const task = payload?.data ?? payload;
  if (!task?.task_id || !task?.task_status) {
    throw new Error("Kling response is missing task identity or status");
  }
  return task;
}

async function refreshVideoJob(job, apiKey) {
  const response = await fetch(job.queryUrl, {
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (!response.ok) {
    throw new Error(`Task query failed with HTTP ${response.status}`);
  }

  const task = normalizeKlingTask(await response.json());
  const outputUrl = task.task_result?.videos?.[0]?.url ?? null;

  return {
    ...job,
    providerTaskId: task.task_id,
    providerStatus: task.task_status,
    terminal: TERMINAL.has(task.task_status),
    outputUrl,
    failureDetail: task.task_status_msg ?? null,
    checkedAt: new Date().toISOString(),
  };
}

Este ejemplo deliberadamente no traduce cada posible estado intermedio del proveedor a una promesa de producto. Tu worker mantiene activas las tareas no terminales, maneja explícitamente succeed y failed, y registra el estado bruto del proveedor para depuración. Añade un tiempo de espera de aplicación aparte para que una tarea detenida no permanezca abierta indefinidamente.

Usa el sondeo como base porque el ID de la tarea permanece consultable. Cuando el endpoint seleccionado admita callback_url, un webhook puede reducir las solicitudes repetidas de estado, pero no debería convertirse en tu único mecanismo de recuperación. La guía oficial de sondeo y webhook señala que las cargas útiles de callback pueden ser específicas del proveedor. Almacena el evento bruto, vuelve idempotente el procesamiento por ID de tarea, devuelve rápidamente una respuesta HTTP exitosa y reconcilia el estado terminal mediante sondeo.

Lista de verificación de producción para equipos de desarrollo

• Valida el modelo en tiempo de ejecución. Revisa el catálogo actual y falla de forma clara cuando un modelo solicitado no esté disponible. No sustituyas silenciosamente un modelo diferente si el comportamiento de salida importa.
• Separa el envío de la recuperación. Almacena el ID de tarea de CometAPI, tu propio ID de trabajo, el modelo seleccionado y marcas temporales para que los reintentos no creen trabajo duplicado.
• Acota el sondeo. Usa un tiempo de espera, backoff exponencial o un intervalo fijo razonable y un número máximo de reintentos. Revisa la guía de límites de tasa y concurrencia de CometAPI antes de aumentar el paralelismo.
• Clasifica los errores. No reintentes parámetros inválidos ni fallas de autenticación. Aplica backoff a errores reintentables de límites de tasa y de la plataforma, siguiendo la guía actual de reintentos y códigos de error.
• Protege credenciales y entradas. Mantén las claves de API del lado servidor, evita registrar secretos y confirma que los usuarios tengan derechos sobre los prompts, imágenes u otros recursos fuente que envíen.
• Mide el trabajo completo. Registra éxito de envío, tiempo en cola, tiempo de generación, tasa de fallas terminales, tasa de timeout, éxito de recuperación de salida y costo por modelo y modo.
• Persiste las salidas deliberadamente. Descarga los recursos completados a un almacenamiento bajo tu control cuando tu producto necesite acceso duradero, luego aplica tu política de retención y eliminación.

Preguntas frecuentes prácticas

¿Necesito una cuenta de desarrollador de Kling por separado para esta vía?

No aparece un paso de incorporación de desarrollador de Kling separado en el flujo de integración de CometAPI. Usas una cuenta y clave de API de CometAPI. El acceso aún depende de que el modelo esté disponible para tu cuenta y región de CometAPI, así que confirma eso antes de comprometerte a producción.

¿El API de Kling es totalmente compatible con OpenAI?

No para el flujo de video mostrado aquí. Usa rutas específicas de Kling como /kling/v1/videos/text2video y campos específicos de Kling. Puedes gestionar la credencial a través de CometAPI, pero tu adaptador debe preservar el esquema específico del proveedor.

¿Qué ID de modelo de Kling debería usar?

La referencia actual de texto a video de CometAPI usa kling-v3 en su primer ejemplo funcional y lista varias ramas anteriores. Usa un ID de modelo del enum del endpoint en vivo y verifica que esté habilitado para tu cuenta. No asumas que el modelo más nuevo está disponible en todas partes.

¿Por qué la primera respuesta no contiene un video?

La generación de video se ejecuta como una tarea asíncrona. La respuesta inicial devuelve un ID de tarea. Sondea la ruta de consulta correspondiente hasta que task_status sea succeed o failed, y luego lee los metadatos del resultado.

¿Debo sondear o usar una URL de callback?

El sondeo es más fácil para una primera integración. Los callbacks reducen solicitudes repetidas a escala pero requieren un receptor autenticado, idempotente y lógica de recuperación. Muchos sistemas en producción usan callbacks como vía principal y el sondeo como respaldo.

¿Puedo usar imagen a video a través del mismo endpoint?

No. CometAPI documenta imagen a video bajo una ruta separada, /kling/v1/videos/image2video. Sigue el esquema de solicitud actual de ese endpoint en lugar de añadir un campo de imagen al ejemplo de texto a video.

¿Debería empezar con modo estándar o profesional?

Usa std para validar autenticación, forma de la solicitud, almacenamiento de la tarea, sondeo y recuperación de la salida. La referencia actual describe pro como un modo de mayor calidad y mayor costo. Evalúalo con prompts representativos solo después de que el flujo básico funcione, y compara la calidad de salida junto con el tiempo de generación y el costo real.

¿Cómo evito generaciones duplicadas durante los reintentos?

Crea un registro de trabajo de la aplicación antes de llamar al API y guarda el ID de tarea del proveedor devuelto inmediatamente. Reintenta las consultas de estado de forma independiente de las solicitudes de creación. No asumas que repetir el mismo POST es idempotente. El endpoint documenta actualmente external_task_id para seguimiento, pero verifica su semántica actual antes de tratarlo como una garantía de desduplicación.

Conclusión

Para un equipo de desarrollo de EE. UU. que desea probar la generación de video de Kling sin completar una solicitud directa de desarrollador de Kling por separado, CometAPI proporciona una vía documentada: verifica que el modelo de Kling requerido esté disponible para la cuenta, autentícate con una clave de CometAPI, llama al endpoint específico del flujo y sigue la tarea asíncrona hasta un estado terminal.

El valor de ingeniería práctico es el acceso centralizado y un modelo de trabajo reutilizable para la aplicación—no la suposición de que cada proveedor de video se comporta de la misma manera. Mantén un adaptador delgado para cada flujo, conserva de forma deliberada la identidad de la tarea y la salida, y conserva el sondeo como ruta de recuperación incluso cuando los callbacks estén habilitados.

Un despliegue seguro es pequeño y medible: valida un modelo y un flujo, envía trabajos cortos de bajo costo, registra las tasas de éxito y fallo terminales, verifica la recuperación de la salida y compara el costo y la latencia reales con los requisitos de tu producto. Amplía a imagen a video u otros flujos de Kling solo después de haber revisado la documentación actual y la cuenta de destino.