Webhook

Un POST d’événement vers une URL HTTPS : accusés de remise, messages entrants, changements de statut à vérifier, accuser réception et mettre en file.

Définitions uniquement : un terme expliqué ici n’est pas un service que nous vendons.

Un webhook est un rappel HTTPS qui pousse un événement vers une URL que vous avez enregistrée, par exemple un accusé de remise ou un message entrant. Le récepteur vérifie la signature, répond 2xx et met le travail en file.

Le récepteur gère doublons et événements hors séquence ; un webhook relève de la livraison push.

Vérifier, accuser, mettre en file

Le fournisseur envoie un POST à chaque événement, et votre point de terminaison renvoie 2xx pour l’accuser. La charge utile est au format JSON avec un type d’événement et un identifiant. Le fournisseur peut la signer ; comparez la signature au corps brut avec le secret partagé et rejetez les requêtes hors de la fenêtre de rejeu.

Vérifiez d’abord, stockez l’événement brut, renvoyez 2xx, traitez en asynchrone. Un point de terminaison lent provoque des réessais. La livraison est au moins une fois et l’ordre n’est pas garanti : dédupliquez sur l’identifiant d’événement. Conservez une file de messages morts pour les événements intraitables. La fiche SMPP versus HTTP compare les rappels à une livraison fondée sur une session.

Questions fréquentes

Quelle est la différence entre un webhook et une API ?

Une API est interrogée par le client ; un webhook est poussé par le fournisseur quand un événement se produit. La plupart des plateformes proposent les deux.

Pourquoi les événements arrivent-ils deux fois ?

La livraison est au moins une fois : un réessai peut dupliquer un événement déjà traité. Dédupliquez sur l’identifiant d’événement.

Quel statut dois-je renvoyer ?

Un 2xx une fois l’événement persisté ou mis en file. Le renvoyer plus tôt risque de perdre l’événement si l’étape suivante échoue.

En savoir plus

Sources

  1. IETF RFC 9110 : sémantique HTTP