webhook.url en una tarea y enviaremos el resultado por POST cuando la tarea llegue a un estado final:
COMPLETED o FAILED.
Payload de entrega
Enviamos por POSTContent-Type: application/json con este cuerpo:
object
requerido
Los mismos metadatos de tarea que recibiste al enviar, ahora con un
status final y tu idempotencyKey de vuelta.object
requerido
El coste en créditos del motor:
2 para Perplexity, 3 para ChatGPT, etc. (1–3 créditos según el motor).
creditsCharged es 0 si la tarea falló. A diferencia de las respuestas de envío y sondeo, que siempre informan
cero, este campo no es cero.object
requerido
El resultado específico del motor. Consulta Motores. En una tarea fallida es
{ "error": "<reason>" } en lugar del resultado del motor.Reintentos
Devuelve cualquier2xx para confirmar. Cualquier otra cosa, incluido un timeout, cuenta como fallo y
reintentamos con backoff exponencial:
Tras el quinto intento la entrega se abandona y se registra. No hay cola de mensajes fallidos que puedas leer.
Para obtener el resultado mediante la API de tareas, sondea dentro de la ventana pública de 24 horas. Esa ventana
no define la vida útil del registro subyacente.
Cada intento tiene un timeout de 30 segundos.
Escribir un handler seguro
1
Confirma rápido
Devuelve
200 en cuanto hayas encolado el payload de forma persistente. Haz el parseo y las escrituras en base
de datos después. Un handler lento agota el timeout de 30 segundos y provoca un reintento que no querías.2
Deduplica por idempotencyKey
Por los reintentos, tu handler puede recibir legítimamente la misma tarea más de una vez. Compara por
task.idempotencyKey (o task.id) y haz la escritura idempotente.3
Ramifica por estado, no por presencia
Comprueba
task.status === "FAILED" de forma explícita. Una tarea fallida también entrega un webhook.Las solicitudes de webhook no llevan firma ni secreto compartido. Si tu endpoint es público, trata el payload como
no confiable y usa una ruta de URL imposible de adivinar, o coloca el handler detrás de restricciones de red.