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 commefailed
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 de60
secondes.
Chaque tentative allonge ce délai de manière exponentielle suivant ce morceau de code:
- 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.