Cet article explique pourquoi CloudTalk désactive automatiquement un endpoint de webhook qui échoue en continu, et comment le remettre en service, y compris récupérer les événements manqués.
Pourquoi un endpoint est désactivé
Lorsqu’une livraison vers votre endpoint de webhook ne reçoit pas de réponse réussie (2xx), CloudTalk la relance automatiquement, jusqu’à 50 fois sur environ 11,5 heures. Si votre endpoint continue d’échouer sans interruption pendant environ 5 jours, CloudTalk le désactive automatiquement et cesse de lui envoyer des événements. Cela évite qu’un endpoint défaillant accumule un nombre infini de livraisons échouées. Les admins du compte reçoivent un e-mail lorsqu’un endpoint est désactivé, puis un autre lorsqu’il est réactivé.Comment le remettre en service
- Corrigez votre endpoint pour qu’il renvoie une réponse HTTP 2xx aux requêtes de webhook entrantes.
- Si vous le corrigez dans les 12 heures qui suivent sa désactivation, vous n’avez rien d’autre à faire. Pendant ces 12 heures, CloudTalk continue de tester votre endpoint. Dès qu’il répond correctement, CloudTalk le réactive automatiquement et renvoie les événements manqués.
- Si plus de 12 heures se sont écoulées, réactivez vous-même l’endpoint :
- Accédez à Paramètres > Webhooks et ouvrez l’endpoint.
- Réactivez l’endpoint.
- Utilisez Recover pour renvoyer les livraisons qui ont échoué pendant sa désactivation.
Combien de temps les événements manqués sont conservés
Les payloads des événements sont conservés pendant 30 jours. Pendant cette période, vous pouvez renvoyer des événements individuels ou récupérer les livraisons échouées. Après 30 jours, ils sont supprimés et ne peuvent plus être renvoyés. Pour le calendrier complet des relances et des conseils pour concevoir un endpoint fiable, consultez Webhook Delivery, Retries, and Best Practices.Besoin d’aide ou une question ? Écrivez-nous via notre Portail Support. Nous sommes là pour vous.