Lorsqu'un webhook est mis en place, vous vous attendez à ce que des informations soient envoyées d'Urbantz à un autre système, sur la base de certains déclencheurs. Pour diverses raisons, le point de terminaison (endpoint) de réception peut être indisponible et les webhooks peuvent ne pas être reçus et traités.
Deux options permettent de minimiser l'impact de l'indisponibilité d'un endpoint : les notifications par e-mail et le System Monitor. Cet article se concentre sur l'option e-mail.
Aperçu:
Configuration
Contenu de l'email
Mécanisme de relance des webhooks
- Webhooks - renvoyer
1. Configuration
Lors de la configuration des webhooks, vous verrez une option qui, s'il elle est activée, vous permet de saisir une adresse électronique à laquelle les notifications d'échec des webhooks doivent être envoyées.
Un e-mail sera envoyé si, après une première tentative d'envoi d'un webhook et deux retraits supplémentaires, nous n'avons pas pu livrer le webhook avec succès (= 3 tentatives au total).
Pour éviter de spammer l'adresse e-mail, les e-mails ne sont pas envoyés en temps réel.
Nous regroupons les retours que nous recevons et envoyons un e-mail toutes les 5 minutes (s'il y a eu des tentatives infructueuses dans cette plage de 5 minutes).
Dans ce cas, le fichier JSON contient tous les webhooks faillis.
❗ Cette notification d'erreur ne peut être envoyée qu'à une seule adresse e-mail
L'erreur "Webhook n'a pas pu être atteint" n'est envoyée que lorsque nous connaissons un délai d'attente et n'avons donc pas reçu de réponse du terminal.
2. Contenu de l'email
Ci-dessous, nous décrivons un exemple de code d'erreur possible. Le message vous indiquera toujours quelle notification (Webhook) exactement a mal fonctionné:
URL de destination: L'url de destination correspond à l'adresse du serveur HTTP pour lequel sont destinés les notifications. (p.e. des notifications webhook).
Unsuccessful payloads (#): nombre de fois où les données JSON n'ont pas étés complétées ou ont échouées.
Encountered errors: Le type d'erreurs qui peuvent avoir lieu. Dans ce champ, nous retournons le code d'erreur HTTP et la description renvoyée par le terminal auquel la notification (webhook) a été envoyée. Ces codes d'erreur ne sont pas générés par Urbantz mais récupérés et ajoutés à l'email. Qui sera envoyé toutes les 5 minutes et qui regroupera les erreurs.
Attaché: le ou les payload(s) sous format JSON.
Grâce à ces e-mails, vous pouvez télécharger les informations manquantes dans le système à mettre à jour et agir sur le problème que rencontre le point de terminaison (endpoint).
3. Mécanisme de relance des webhooks
Si l’envoi d’un webhook échoue, notre système le relance automatiquement jusqu’à 9 fois. Seuls les webhooks qui restent en échec après ces 9 tentatives sont conservés de notre côté. La dernière tentative a lieu 4 heures après l’envoi initial. Il n’existe pas de SLA strict concernant la livraison des webhooks.
4. Webhooks - renvoyer
Si des webhooks échouent de votre côté et que l’indisponibilité dépasse la fenêtre de relance de 4 heures, ces webhooks resteront au statut « failed » et ne seront pas renvoyés automatiquement.
Vous pouvez toutefois demander de renvoyer ces webhooks auprès d’Urbantz et nos équipes pourront les renvoyer pour vous. Veuillez noter:
Il s’agit d’une intervention payante. Pour soumettre une demande, veuillez contacter notre équipe Support, qui fera le relais en interne avec l’équipe Engineering. Vous devez préciser clairement les données à renvoyer (par exemple : webhooks de mise à jour de tâche en échec envoyés entre 13h00 et 17h00 CET).
Nous vous recommandons de fournir un maximum de détails afin de garantir une relecture rapide et précise.
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.