Skip to main content
Fournissez webhook.url sur une tâche et nous y enverrons le résultat en POST quand la tâche atteint un état final : COMPLETED ou FAILED.

​
Charge utile de livraison

Nous envoyons en POST Content-Type: application/json avec ce corps :
​
object
requis
Les mêmes métadonnées de tâche qu’à la soumission, désormais avec un status final et votre idempotencyKey renvoyée.
​
object
requis
Le coût en crédits du moteur : 2 pour Perplexity, 3 pour ChatGPT, etc. (1 à 3 crédits selon le moteur). creditsCharged vaut 0 si la tâche a échoué. Contrairement aux réponses de soumission et de polling, qui indiquent toujours zéro, ce champ n’est pas nul.
​
object
requis
Le résultat propre au moteur. Consultez Moteurs. Pour une tâche échouée, c’est { "error": "<reason>" } au lieu du résultat du moteur.
Une tâche échouée est aussi livrée :

​
Nouvelles tentatives

Renvoyez n’importe quel 2xx pour accuser réception. Tout le reste, timeout compris, est un échec et nous réessayons avec un backoff exponentiel : Après la cinquième tentative, la livraison est abandonnée et journalisée. Il n’existe pas de file de lettres mortes consultable. Pour récupérer le résultat via l’API de tâches, interrogez-la pendant la fenêtre publique de 24 heures. Cette fenêtre ne définit pas la durée de stockage de l’enregistrement sous-jacent. Chaque tentative a un timeout de requête de 30 secondes.
Du point de vue de la tâche, la livraison est de type « envoyer et oublier ». Une tâche terminée dont le webhook ne peut jamais être livré reste COMPLETED sur GET /v1/async/task/{id} : le statut décrit le travail du moteur, pas la notification.

​
Écrire un handler sûr

1

Accuser réception vite

Renvoyez 200 dès que vous avez mis la charge utile en file de façon durable. Faites l’analyse et les écritures en base ensuite. Un handler lent consomme le timeout de 30 secondes et provoque une nouvelle tentative indésirable.
2

Dédupliquer sur idempotencyKey

À cause des nouvelles tentatives, votre handler peut légitimement recevoir la même tâche plusieurs fois. Rapprochez sur task.idempotencyKey (ou task.id) et rendez l’écriture idempotente.
3

Brancher sur le statut, pas sur la présence

Vérifiez explicitement task.status === "FAILED". Une tâche échouée livre aussi un webhook.
Les requêtes webhook ne portent ni signature ni secret partagé. Si votre endpoint est public, considérez la charge utile comme non fiable et utilisez un chemin d’URL impossible à deviner, ou placez le handler derrière des restrictions au niveau réseau.