Muchos equipos que integran Kling empiezan eligiendo un punto de entrada relay o proxy: se cambia la URL base y la clave, y parece más sencillo que conectarse directamente. Pero la generación de video es una tarea asíncrona, y un relay añade capas que una API de texto no necesita: persistencia de tareas, mapeo de estados, reenvío de callbacks y almacenamiento de resultados. Si cualquiera de esas piezas queda débil, el síntoma es siempre el mismo: "la tarea se envió bien, pero el video no aparece".

Este artículo parte del recorrido real de un relay para explicar la fiabilidad de las tareas, la retención de resultados, la transparencia de la facturación y los riesgos de las claves, además de cómo validar una migración desde la conexión directa.

Nota: Kling es una marca o marca registrada de Kuaishou y sus empresas vinculadas. Este artículo solo ofrece una explicación técnica y no implica afiliación ni relación de cooperación con Kuaishou. Las interfaces, los modelos y las reglas de facturación se rigen por la documentación oficial y por precios de modelos del sitio; los precios pueden cambiar.

1. Cuatro tipos de "relay": primero mira qué estás comprando

Tipo Qué ofrece realmente Riesgo principal Escenario adecuado
Proxy inverso Reenvía solicitudes a la interfaz upstream Punto único, ancho de banda de salida, configuración de autenticación Equipos con operaciones que solo quieren una salida unificada
Gateway agregador Entrada única que agrupa varios modelos de video Mapeo de estados, diferencias de parámetros, almacenamiento de resultados Negocios multimodelo, equipos pequeños
Distribución o recarga Revende créditos o paga en nombre del cliente Estabilidad upstream, términos de servicio, seguridad del saldo Pruebas temporales, necesidades pequeñas
Gateway autoalojado Despliegas y mantienes tu propia capa de reenvío Servidores, certificados y protección contra abusos corren por tu cuenta Control de datos y equipo técnico propio

Si compras "servicio técnico" o "créditos de modelo" determina quién responde ante una falla, quién emite la factura y con quién firmas las cláusulas de datos. Revisa contrato y factura según esa diferencia, y no solo porque la página mencione a Kling.

2. Cómo recorren los estados de tarea un relay

Tu negocio
  → Entrada del relay (autenticación, límites, facturación)
  → Upstream crea la tarea y devuelve el id de tarea
  → El relay guarda la relación entre id de tarea y número de pedido
  → El relay consulta el upstream o recibe callbacks
  → Traduce a un estado unificado y expone consulta o webhook
  → Tú descargas el resultado y lo almacenas

En la interfaz nueva oficial, los estados de tarea suelen ser submitted, processing, succeeded y failed; en la antigua, el éxito puede aparecer como succeed. Si el relay solo mapea éxito y fallo, el negocio puede quedarse esperando processing para siempre; si la tarea upstream expira, también debe existir una salida como expired.

Cada salto adicional es un punto donde se puede perder el estado: el relay se reinicia y el mapeo en memoria desaparece; el upstream ya creó la tarea pero el relay devuelve error y el cliente reintenta, generando dos tareas; el callback no tiene clave de idempotencia y el negocio duplica registros. Al evaluar, pregunta: dónde se guarda el ID de tarea, cuánto tiempo, si se puede buscar por número de pedido y cómo se compensa un fallo.

3. Retención y almacenamiento de resultados

La documentación oficial indica que las URL de resultado se eliminan a los 30 días y que la dirección incluye un formato de protección contra enlaces externos. Un relay suele aplicar una de tres estrategias, con responsabilidades muy distintas:

  • Reenviar la dirección upstream: el cliente asume la responsabilidad de almacenar el video dentro de los 30 días.
  • Dirección en caché o proxy: hay que especificar si se vuelve al origen al expirar, cuánto dura la caché y si tiene costo adicional.
  • Almacenamiento gestionado: el relay descarga y conserva el resultado a largo plazo; hay que confirmar ubicación, permisos de acceso, mecanismo de borrado y plazo de retención.

El "enlace permanente" suena cómodo, pero si el relay solo apunta su propio dominio a una dirección upstream que expira, dejará de funcionar igual. En la validación conviene acceder una vez 24 horas después del éxito y otra cerca de los 30 días para confirmar que el enlace sigue disponible.

4. Cómo verificar la transparencia de la facturación

El video de Kling suele facturarse por una combinación de segundos, resolución y activación de audio o control de movimiento, y también puede usar paquetes de recursos y cupos de concurrencia. Un relay puede añadir un margen, fijar un consumo mínimo o ajustar la vigencia de los paquetes, así que no basta con mirar el descuento promocional.

Para conciliar, exige al menos: ID de tarea, número de pedido, modelo, duración, resolución, estado, importe descontado y moneda. El campo billing del callback oficial distingue entre cargo en efectivo y descuento de paquete de recursos, e indica importe, moneda y tipo de plan; que el relay exponga esos campos tal cual es un indicio directo de transparencia.

También confirma si se facturan los fallos, los timeouts, las cancelaciones y los rechazos de moderación, si hay deduplicación idempotente para envíos repetidos y cómo se gestionan reembolsos y facturas. Los precios concretos se rigen por precios de modelos del sitio. Antes de firmar, ejecuta de 20 a 50 tareas pequeñas durante una semana y compara una por una las cifras de éxito, fallo y facturación.

5. Claves, datos y riesgos upstream

Cuando las solicitudes pasan por un tercero, los prompts, las imágenes iniciales y los videos generados pueden ser vistos o almacenados. Antes de comprar, confirma:

  1. Si la clave permite limitar cuota, IP y vigencia, y si se puede bloquear rápido tras una filtración.
  2. Si las solicitudes y los resultados se almacenan, durante cuánto tiempo, dónde y quién tiene acceso.
  3. Si los datos se usan para entrenamiento o mejora del servicio y si es posible desactivarlo.
  4. Si el upstream es un solo canal o varios, y cómo se notifican las bajas de modelos o los cambios de versión.
  5. Si los términos de servicio permiten reventa o proxy, y cuál es el límite de responsabilidad ante disputas.
  6. Quién firma los callbacks, cuál es la ventana de tiempo permitida y cómo se rechazan las solicitudes repetidas.

Las claves de producción no deben ir en el frontend, en el repositorio ni en capturas de tickets. Para material muy sensible, prioriza proveedores que no almacenen datos o que permitan firmar un acuerdo; si no puedes confirmarlo, anonimiza antes de subir. La clave de Kling suele mostrarse completa una sola vez en la consola; si la pierdes, crea una nueva en lugar de adivinarla.

6. Pasos para migrar de conexión directa a relay

  1. Inventaria las llamadas actuales: modelos, parámetros, concurrencia, duración media y tipos de fallo.
  2. Prepara una tabla de equivalencias de interfaz: dominio, autenticación, campos, valores de estado y códigos de error.
  3. Recorre las cuatro rutas en el entorno de prueba: creación, consulta, callback y descarga.
  4. Haz una ejecución en sombra con el mismo lote: una copia por conexión directa y otra por relay, solo comparando, sin cambiar el tráfico.
  5. Compara tasa de éxito, latencia P95, proporción de resultados descargables y costo por video exitoso.
  6. Cambia el tráfico de forma gradual entre 5% y 20%, manteniendo un interruptor para volver a la conexión directa.
  7. Observa de 3 a 7 días y confirma que la factura, el detalle de tareas y los números de pedido coinciden.
  8. Tras el cambio completo, conserva un periodo con doble canal de respaldo y simplifica la arquitectura cuando se estabilice.

Durante la migración no borres la clave de conexión directa ni escribas las dos versiones de una tarea bajo el mismo número de pedido; de lo contrario, no podrás distinguirlas al conciliar.

7. Cómo validar un relay

# 1. Envía la tarea mínima y registra id de tarea, número de pedido y hora de envío
curl -X POST "$RELAY_BASE_URL/text-to-video/kling-2.6" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "un gato bostezando junto a la ventana",
    "settings": {"duration": 5, "resolution": "720p", "aspect_ratio": "16:9"},
    "options": {"external_task_id": "relay-test-20261019-01"}
  }'

# 2. Consulta cada 10 segundos y registra toda la transición de estados y los errores
curl "$RELAY_BASE_URL/tasks?task_ids=$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

En las pruebas provoca anomalías a propósito: cancela justo después de enviar, usa un ID de modelo incorrecto, supera el límite de concurrencia, corta la descarga a mitad y repite un callback. Observa si el estado, el código de error y el cargo que devuelve el relay son coherentes. Accede a la dirección del resultado después de 24 horas, consulta el registro de la tarea a los 7 días y vuelve a comprobar cerca de los 30 días si el enlace y el registro siguen existiendo.

8. Monitoreo y reversión tras la migración

  • Cuenta las tareas por estado y presta atención a la proporción de failed, cancelled y tareas expiradas.
  • Registra el tiempo total desde el envío hasta el éxito y separa el tiempo en cola del tiempo de generación.
  • Monitorea la tasa de descarga correcta; las tareas fallidas deben entrar en una cola de compensación, no en reintentos infinitos.
  • Cuenta los errores 401, 404, 429 y 5xx, y distingue entre clave, modelo, concurrencia y fallo upstream.
  • Calcula el costo por video exitoso, no solo el precio de una solicitud.
  • Define un umbral de reversión; por ejemplo, si la tasa de éxito cae claramente por debajo de la línea base durante dos horas seguidas, vuelve a la conexión directa.

Preguntas frecuentes

¿El video generado por un relay es igual al de la conexión directa?

Depende de si el relay reenvía el mismo modelo upstream y los mismos parámetros. Puede haber diferencias de versión de modelo, duración, resolución y audio; antes de integrar, ejecuta varias pruebas con el mismo prompt y los mismos parámetros.

¿El relay guarda mis videos?

Cada servicio es distinto. Pregunta si almacena, durante cuánto tiempo, dónde, quién puede acceder y cómo funciona el borrado. Cuando se trata de material de clientes, prioriza proveedores con términos claros.

¿Qué hago si la tarea se pierde en el relay?

Busca primero en tus registros por número de pedido, y después en los logs del relay y en la tarea upstream. Si no se puede recuperar, solo queda volver a enviarla. Por eso, antes de migrar, confirma si el relay persiste el mapeo de tareas y si permite buscar por número de pedido.

¿Qué hago si la factura no coincide con el número de tareas?

Las causas habituales son envíos duplicados, reintentos fallidos, reglas de cancelación distintas, consumo mínimo o paquetes vencidos. Solicita el detalle de cargos por ID de tarea y revísalo uno por uno, no solo el total.

¿Cuánto código hay que cambiar para migrar?

Si el relay es compatible con la interfaz oficial de tareas, normalmente solo cambian el dominio, la clave y algunos campos; si el mapeo de estados o el formato de callback es distinto, hay que modificar el polling y la lógica de registro. Una ejecución en sombra detecta la mayoría de las diferencias con antelación.

Próximos pasos

Crea primero una clave de prueba en ZSQH AI Gateway, valida con la tarea mínima las cuatro rutas (creación, polling, callback y facturación) y después migra de forma gradual. Los modelos y precios se rigen por precios de modelos, y la disponibilidad de video Kling por la documentación del sitio.

Lecturas relacionadas: