Skip to main content
Muitos endpoints de mídia são assíncronos. Um pedido de criação inicia o trabalho e retorna uma identidade de tarefa pública do TokenLab; sua aplicação consulta até que essa tarefa atinja um status terminal. Não construa fluxos de trabalho do cliente em torno de URLs de tarefas upstream, IDs de roteamento ou comportamento de callback do provedor.

Contrato de Tarefa Pública

As respostas de criação podem incluir: /v1/tasks/{id} é o endpoint de status fixo canônico para trabalhos de mídia assíncronos públicos. Rotas de status específicas de mídia podem existir para compatibilidade, mas novas integrações devem preferir poll_url ou /v1/tasks/{id}.

Fluxo Recomendado

  1. Valide o pedido do usuário e envie a chamada de criação com um model explícito.
  2. Persista id / task_id, poll_url, endpoint, modelo, ID do usuário e seu próprio ID de trabalho antes de retornar o controle para a UI.
  3. Consulte a cada 5-10s para tarefas de mídia de longa duração.
  4. Pare somente quando a tarefa estiver completed ou failed.
  5. Ao completed, leia os campos de resultado específicos de mídia e armazene URLs ou metadados finais.
  6. Ao failed, armazene o erro público e ofereça a tentativa novamente apenas como um novo trabalho visível ao usuário.

Exemplo de Polling

Os status públicos esperados são pending, processing, completed e failed. Tarefas canceladas são representadas como failed com cancelled: true e cancellation_status: "cancelled" para que o manuseio de status mais antigos continue funcionando.

Regras de Tentativa do Cliente

Os timeouts de rede são a fonte mais comum de trabalhos duplicados. Use esta regra: Não envie um segundo pedido de criação apenas porque o navegador foi atualizado ou uma consulta de status falhou.

Cobrança e Liquidação

Trabalhos assíncronos podem reservar um valor estimado quando o pedido de criação é aceito. A liquidação final acontece após o status terminal. Quando disponível, as respostas de status da tarefa podem expor billing_transaction_id e o cabeçalho X-Billing-Transaction-ID. Para reconciliação, junte esses identificadores em seus logs:
  • request_id do pedido de criação.
  • task_id / id da tarefa.
  • billing_transaction_id quando presente.
  • Seu próprio ID de usuário, ID de projeto ou ID de trabalho.

Cancelamento

DELETE /v1/tasks/{id} é intencionalmente restrito. Quando a tarefa selecionada oferece cancelamento, ele se aplica a tarefas de vídeo Seedance em fila como seedance-1.5-pro, seedance-2.0 e seedance-2.0-fast. Tarefas não suportadas retornam 400 unsupported_task_cancel. Tarefas que já estão em execução ou em status terminal retornam 409 task_not_cancellable. Construa a UI de cancelamento como “solicitar cancelamento” em vez de um botão de parada garantido.

Solução de Problemas

Pacote de Suporte

Ao entrar em contato com o suporte, inclua request_id, task_id, billing_transaction_id quando presente, endpoint, modelo, timestamp e uma forma de pedido sanitizada. Não inclua chaves de API, mídia privada, URLs assinadas ou prompts completos, a menos que o suporte peça um exemplo redigido.

Referência da API