Tasks e webhooks

POST de affiliate e fetch não espera o scraping terminar. A API enfileira o trabalho no Celery e responde na hora.

Resposta 202

O body segue TaskAcceptedResponse:

{
  "task_id": "abc-123",
  "status_url": "/v1/tasks/abc-123/status",
  "task_ids": ["abc-123", "def-456"]
}

• task_id / status_url — primeira task criada
• task_ids — todas as tasks (affiliate: uma task por URL, máximo 25; fetch: um item)

Consulte cada uma:

curl http://localhost:8000/v1/tasks/abc-123/status \
  -H "x-api-key: SUA_CHAVE"

A consulta é isolada por tenant: uma chave não vê task de outra.

Status

Valores persistidos no código:

O campo result é um objeto livre (não há schema Pydantic fechado). Os exemplos no OpenAPI refletem o que os workers/adapters montam hoje.

Webhook (saída do worker)

Não é um endpoint desta API. O worker chama a URL que você cadastrou.

Ordem de escolha da URL:

1. webhook_override no body do POST (se enviado)
2. webhook_url da conta no cofre

Quando dispara, o worker envia HMAC-SHA256 no header X-Omnilink-Signature (JSON canônico com sort_keys, até 3 tentativas, timeout 10 s). Segredo: WEBHOOK_SIGNING_SECRET.

Use o webhook para não ficar em polling. Continue usando GET /v1/tasks/{task_id}/status como fonte da verdade se a entrega falhar.