Prévoir les répétitions dans les intégrations webhook

Lors de la conception d’une intégration webhook, les livraisons répétées doivent être considérées comme un cas de fonctionnement possible. Le choix logiciel doit prévoir ce qui arrive à l’action métier lors de la deuxième réception. Une connexion fiable ne répond pas, à elle seule, à cette question.

Un signal perdu laisse l’issue incertaine

Dans un portail client fictif, une notification déclenche la création d’une commande dans l’ERP. La commande est créée, mais la réponse ne parvient pas à l’émetteur. Celui-ci renvoie la notification. Si chaque réception crée aveuglément une commande, une même action produit deux commandes.

Stripe indique explicitement que des événements peuvent être livrés plusieurs fois. Il s’agit d’un cas précis chez un fournisseur. Vous devez examiner le contrat de votre propre connexion pour savoir quelles répétitions elle peut produire. L’absence d’accusé de réception ne permet de conclure ni à un succès certain ni à un échec certain.

Évaluer la répétition par son effet métier

Dans cet exemple, la règle souhaitée permet à la même notification de retrouver la commande existante plutôt que d’en créer une autre. L’intégration nécessite une identité convenue et une association fiable avec le résultat du traitement. La protection doit aussi tenir compte de deux copies reçues simultanément ; vérifier puis enregistrer plus tard, dans des étapes indépendantes, laisse cette question ouverte.

Dans le scénario de recette, vérifiez la commande dans l’ERP, la réponse à la nouvelle tentative et l’état visible dans le portail. Un accusé de transport et une commande finalisée peuvent correspondre à des états différents.

L’effort dépend de l’action

Si une notification se contente de réaffecter une valeur d’affichage déjà identique, sa répétition peut être sans conséquence. La création d’une commande ou un autre effet prévu une seule fois nécessite davantage de protection. Cela n’impose pas d’ajouter une file d’attente à chaque petite connexion.

Les répétitions doivent rester visibles. Leur augmentation peut signaler une panne. Nous recommandons de gérer les répétitions attendues tout en conservant la possibilité d’examiner les comportements inhabituels.

Sources

• Stripe: Webhooks, duplicate events