Skip to main content

​
Nombre d’appels HTTP envoyés

Votre point de terminaison peut recevoir plusieurs appels HTTP pour un même événement, selon l’événement. Lorsqu’une transaction atteint un statut final comme failed ou successful, le webhook correspondant est normalement envoyé une seule fois. Pour les statuts intermédiaires comme pending ou action_required, le webhook peut être envoyé plusieurs fois. Cela se produit lorsque les données de l’opérateur changent : l’API HUB2 a reçu une mise à jour de l’opérateur, mais pas une mise à jour qui détermine le statut final de la transaction. Un envoi relancé (voir ci-dessous) atteint aussi votre point de terminaison plusieurs fois. Toutes les tentatives pour un même événement portent le même id d’événement, que vous pouvez utiliser pour ignorer les doublons. Un statut peut aussi être notifié à nouveau sous la forme d’un nouvel événement avec un nouvel id, par exemple lorsque le support HUB2 renvoie un webhook. Rendez votre traitement idempotent sur l’objet (data.id) et son statut, pas seulement sur l’id d’événement.

​
En cas d’échec HTTP

Si l’URL de destination est injoignable pour une raison quelconque (panne réseau, serveur indisponible, etc.), l’appel HTTP échoue. Pour y remédier, l’API HUB2 relance les envois en échec. C’est le comportement par défaut. Avec la stratégie no_retry définie dans le dashboard, un envoi en échec n’est pas relancé et le webhook n’est pas désactivé.

​
Stratégie de relance

Après un envoi en échec, le webhook est renvoyé après un délai initial de 60 secondes. Chaque nouvel échec allonge ce délai de manière exponentielle, selon cette formule :
Cela donne les délais suivants avant chaque relance :
  1. 1 minute
  2. 3 minutes
  3. 7 minutes
  4. 15 minutes
  5. 31 minutes
  6. 63 minutes
  7. 127 minutes
  8. et ainsi de suite, en doublant à chaque fois.
Les relances ne durent pas indéfiniment. Si l’envoi échoue encore après 10 relances (11 tentatives au total, environ 34 heures après la première), l’API HUB2 considère l’URL de destination comme injoignable, arrête les relances et désactive automatiquement le webhook.

​
Délai d’attente (timeout)

Si l’URL de destination met plus de 5 secondes à répondre, l’API HUB2 cesse d’attendre et considère l’appel comme un échec.
Un dépassement du délai déclenche la stratégie de relance : un point de terminaison lent est donc une cause fréquente de réception multiple d’un même webhook.

​
Désactivation automatique

Un webhook désactivé le reste jusqu’à ce que vous le réactiviez. Les événements qui surviennent pendant la désactivation ne sont pas envoyés : veillez donc à ce que cela n’arrive jamais. Les envois encore en attente ou en cours de relance au moment de la désactivation sont également abandonnés. Après la réactivation, récupérez le statut des transactions concernées via l’API. Vous pouvez réactiver le webhook à tout moment en repassant son status à enabled via l’API.
Mettre à jour un webhook
Pour éviter la désactivation, le point de terminaison qui reçoit le webhook doit toujours renvoyer un code HTTP 2xx. Toute autre réponse, ou l’absence de réponse, est considérée comme un échec. Une fois les relances épuisées, le webhook est désactivé automatiquement.