Skip to main content
Muchos endpoints de medios son asíncronos. Una solicitud de creación inicia el trabajo y devuelve una identidad de tarea pública de TokenLab; tu aplicación consulta hasta que esa tarea alcanza un estado terminal. No construyas flujos de trabajo de clientes alrededor de URLs de tareas ascendentes, IDs de enrutamiento o comportamiento de callbacks del proveedor.

Contrato de Tarea Pública

Las respuestas de creación pueden incluir: /v1/tasks/{id} es el endpoint de estado fijo canónico para trabajos de medios asíncronos públicos. Pueden existir rutas de estado específicas de medios para compatibilidad, pero las nuevas integraciones deberían preferir poll_url o /v1/tasks/{id}.

Flujo Recomendado

  1. Valida la solicitud del usuario y envía la llamada de creación con un model explícito.
  2. Persiste id / task_id, poll_url, endpoint, modelo, ID de usuario y tu propio ID de trabajo antes de devolver el control a la UI.
  3. Consulta cada 5-10s para tareas de medios de larga duración.
  4. Detente solo cuando la tarea esté completed o failed.
  5. En completed, lee los campos de resultado específicos de medios y almacena las URLs finales o metadatos.
  6. En failed, almacena el error público y ofrece reintentar solo como un nuevo trabajo visible para el usuario.

Ejemplo de Polling

Los estados públicos esperados son pending, processing, completed y failed. Las tareas canceladas se representan como failed con cancelled: true y cancellation_status: "cancelled" para que el manejo de estados más antiguos siga funcionando.

Reglas de Reintento del Cliente

Los tiempos de espera de red son la fuente más común de trabajos duplicados. Usa esta regla: No envíes una segunda solicitud de creación solo porque el navegador se refrescó o una consulta de estado falló.

Facturación y Liquidación

Los trabajos asíncronos pueden reservar una cantidad estimada cuando se acepta la solicitud de creación. La liquidación final ocurre después del estado terminal. Cuando esté disponible, las respuestas de estado de tarea pueden exponer billing_transaction_id y el encabezado X-Billing-Transaction-ID. Para la reconciliación, une estos identificadores en tus registros:
  • request_id de la solicitud de creación.
  • task_id / id de la tarea.
  • billing_transaction_id cuando esté presente.
  • Tu propio ID de usuario, ID de proyecto o ID de trabajo.

Cancelación

DELETE /v1/tasks/{id} es intencionalmente limitado. Cuando la tarea seleccionada admite cancelación, se aplica a tareas de video Seedance en cola como seedance-1.5-pro, seedance-2.0 y seedance-2.0-fast. Las tareas no soportadas devuelven 400 unsupported_task_cancel. Las tareas que ya están en ejecución o en estado terminal devuelven 409 task_not_cancellable. Construye la UI de cancelación como “solicitar cancelación” en lugar de un botón de parada garantizado.

Solución de Problemas

Paquete de Soporte

Al contactar con soporte, incluye request_id, task_id, billing_transaction_id cuando esté presente, endpoint, modelo, marca de tiempo y una forma de solicitud sanitizada. No incluyas claves API, medios privados, URLs firmadas o prompts completos a menos que el soporte pida una muestra redactada.

Referencia de API