Skip to main content
Algumas operações chamam provedores externos (transcriber, LLM, API do YouTube) e podem levar de segundos a minutos. Em vez de bloquear, esses endpoints aceitam o trabalho e retornam na hora com HTTP 202 e uma execution que você acompanha até concluir.

Quais endpoints são assíncronos

Todo o resto (leituras, CRUD de collections/reporters/workflows/schedules) é síncrono — devolve o resultado final direto.

O ciclo de vida da execution

O corpo do 202 te dá uma execution com execution_id e um status inicial:

Acompanhar até concluir (polling)

Faça polling da execution até sair de pending/running:
O detalhe inclui a execution, o workflow que rodou, os summaries por step (input/output da LLM) e step_inputs dos steps ainda não executados.
Pra ver tudo que está rodando agora, chame GET /v1/executions/me?active=1 — retorna só executions pending/running. Útil pra um dashboard ou indicador de “ainda processando”.

Realtime (só o app)

O app web não faz polling — ele assina o WebSocket de realtime (wss://api.clipping.cc/v1/realtime?token=<jwt>) e recebe mensagens event conforme as executions avançam.
O WebSocket autentica só com JWT de sessão (no query param token) — uma API key não abre. Se você integra com API key, faça polling de GET /v1/executions/{id} como acima.

Custo

O próprio 202 debita a taxa flat da rota (ex.: 0,01 coin pra rodar um transcript). O custo real do provedor é debitado por pass-through do dono do recurso enquanto o job roda — então um job ainda pode terminar em 402 se o dono ficar sem saldo no meio.