Comportement des webhooks
Nombre d’appels HTTP envoyés
La destination d’un webhook peut recevoir plusieurs appels HTTP pour un même événement, selon l’événement.
À chaque fois qu’une transaction arrive dans un statut final comme failed
ou success
, le webhook concerné ne devrait être envoyé qu’une seule fois.
Par contre pour les statuts intermédiaires comme pending
ou action_required
, il peut y avoir plusieurs appels HTTP. Cela arrive si les données de l’opérateur ont changé, cela signifie que l’API HUB2 a reçu une mise à jour du côté de l’opérateur mais cette mise à jour est insuffisante pour déterminer le statut final de la transaction.
En cas d’échec HTTP
Dans le cas où l’URL distante n’est pas joignable pour n’importe quelle raison (échec réseau, indisponibilité du serveur, …), l’appel HTTP va échouer.
Pour pallier cette éventualité, l’API HUB2 dispose d’une stratégie de re-jeu.
Stratégie de re-jeu
En cas d’échec, un webhook est “rejoué” après un délai de 60
secondes.
Chaque tentative allonge ce délai de manière exponentielle suivant ce morceau de code:
Exemple de délais pour chaque Nième tentative:
- Attente de 1 minute
- Attente de 3 minutes
- Attente de 7 minutes
- Attente de 15 minutes
- Attente de 31 minutes
- Attente de 63 minutes
- Attente de 127 minutes
- etc..
La stratégie de re-jeu ne dure pas éternellement. Après 10
tentatives, le webhook va considérer l’URL de destination comme inaccessible et le re-jeu s’arrête. Cela va arriver après ~34 heures.
Timeout
Toute URL de destination d’un webhook qui prend plus de 5 secondes à répondre déclenchera un timeout dans l’API HUB2 et sera considéré comme un échec.
Si un tel scénario devait arriver, cela déclenchera la stratégie de re-jeu et peut représenter une cause pour laquelle plusieurs fois le même webhook est reçu.
Désactivation automatique
Cette désactivation n’est que temporaire et vise à garder une qualité de service constante de l’API HUB2. Toutefois, afin d’éviter tout souci de qualité d’intégration, il est préférable que cela n’arrive jamais.
Il est possible de réactiver le webhook à tout moment via l’API mise à disposition.
Afin de s’assurer que cette désactivation n’ait pas lieu, le point de terminaison cible au webhook doit toujours retourner un code HTTP 2xx.
Toute autre réponse, ou aucune réponse, sera considérée comme une erreur, et après plusieurs essais, désactivera le webhook automatiquement.