language permet également de choisir la langue du message d’échec.
Démarrage rapide
Lors de la soumission d’une tâche, ajoutezwebhook au niveau supérieur du corps de la requête. Pour traduire les messages d’échec, ajoutez également language :
votre URL + /callback.
Les autres points de terminaison de tâches asynchrones (vidéo, audio, etc.) utilisent
webhook de la même manière. language s’applique actuellement à POST /v1/videos/generations et POST /v1/images/generations ; les deux champs doivent se trouver au niveau supérieur du corps de la requête.Choisir la langue du message d’erreur
language est un paramètre de chaîne facultatif qui affecte uniquement error.message dans les rappels d’échec. L’ID de la tâche, le statut, la progression, le coût et les URL de résultat ne changent pas selon la langue. Si ce paramètre est omis, le message d’erreur d’origine du fournisseur en amont ou de la plateforme est renvoyé.
- Les valeurs ne sont pas sensibles à la casse et les espaces en début et fin sont automatiquement supprimés. Par exemple,
"FR"et" fr "sont tous deux traités commefr. - Utilisez les codes à deux lettres du tableau. Les balises régionales telles que
zh-CN,en-USetpt-BRne sont pas reconnues. - Une valeur non prise en charge ne fait pas échouer la soumission de la tâche ; le rappel conserve le message d’erreur d’origine.
- Si le message d’origine est déjà dans la langue cible, il est renvoyé tel quel sans nouvelle traduction.
- Si la traduction échoue, le message d’origine est renvoyé sans retarder ni abandonner le rappel.
Lors de l’interrogation, utilisez le paramètre de requête
language du point de terminaison de statut pour choisir la même langue du message d’erreur. Un Webhook n’a pas de chaîne de requête : language doit donc être spécifié lors de la soumission de la tâche.Règles d’URL
Lewebhook que vous fournissez est l’URL de base, à laquelle nous ajoutons automatiquement /callback :
Votre serveur doit donc disposer d’un point de terminaison acceptant
POST .../callback.
Ce que vous allez recevoir
Le contenu envoyé est exactement identique à ce que renvoie le point de terminaison « Obtenir le statut d’une tâche » : vous pouvez le traiter avec la même logique d’analyse.Pour les tâches vidéo, le résultat se trouve dans
result.videos, et pour l’audio dans result.audios.L’exemple d’échec ci-dessus utilise
"language": "fr". Le paramètre de langue modifie uniquement error.message ; tous les autres champs restent identiques.Nouvelles tentatives et déduplication (important)
- Nouvelles tentatives : Si votre serveur ne renvoie pas
2xxen environ 10 secondes, ou renvoie5xx, nous réessaierons automatiquement, jusqu’à 3 fois, à des intervalles d’environ 10 s, 30 s et 60 s. Si les 3 échouent, nous abandonnons (en environ 2 minutes). - Pas de nouvelle tentative : Si votre point de terminaison renvoie
4xx(considéré comme une URL / requête incorrecte), nous abandonnons immédiatement sans réessayer. - Déduplication : Normalement, une tâche n’est envoyée qu’une seule fois. Mais dans des cas extrêmes (p. ex. un redémarrage de notre côté après l’envoi mais avant la confirmation), vous pourriez recevoir des envois en double. Veillez à dédupliquer de manière idempotente par
id(task_id) pour éviter un double traitement.
1
Renvoyez 2xx le plus tôt possible
Acceptez et mettez en file d’attente d’abord, puis traitez de manière asynchrone : ne nous faites pas attendre la fin de votre traitement.
2
Dédupliquez par id
Utilisez
id (task_id) comme clé d’idempotence pour éviter un double traitement.3
Configurez et vérifiez la signature
En production, vérifiez l’origine des requêtes de rappel et rejetez les requêtes falsifiées.
Exigences pour l’URL de rappel
Pour des raisons de sécurité, l’URL de rappel doit respecter les conditions suivantes :
Les URL qui ne respectent pas ces exigences sont rejetées (aucun envoi, aucune nouvelle tentative).
FAQ
J'ai soumis une tâche avec un webhook mais je n'ai rien reçu ?
J'ai soumis une tâche avec un webhook mais je n'ai rien reçu ?
Vérifiez point par point :
- La tâche est-elle réellement terminée ? Consultez les détails de la tâche :
statusest-ilcompleted/failed(aucun envoi pendant le traitement) ? - Votre URL est-elle accessible publiquement ? Pouvons-nous atteindre votre
/callback? - Le port est-il un port standard (80 / 443) ? Les ports non standard peuvent être bloqués par les politiques de sécurité.
- Votre
/callbacka-t-il renvoyé 2xx à temps ? En cas de 4xx, nous abandonnons immédiatement. - Utilisez-vous
https? Le certificat est-il valide ?
Pourquoi url dans le résultat est-il un tableau ?
Pourquoi url dans le résultat est-il un tableau ?
Certains modèles produisent plusieurs images à la fois, donc
images[].url peut être un tableau : traitez-le simplement comme un tableau.Les liens de résultat expirent-ils ?
Les liens de résultat expirent-ils ?
Si
result contient expires_at (horodatage Unix), cela indique l’heure d’expiration du lien : transférez-le/sauvegardez-le rapidement.Envoyez-vous le statut « en cours de traitement » ?
Envoyez-vous le statut « en cours de traitement » ?
Non. Nous n’envoyons qu’une seule fois, lorsque la tâche réussit ou échoue définitivement.
Exemple minimal de récepteur
Python
200 le plus tôt possible et exécutez votre logique de traitement de manière asynchrone en arrière-plan.