IOSOR

IOSOR Guides

Webhooks SMS inbound : retries, ordre des événements et idempotence à la réception

Guide B2B du chemin de réception : comment les webhooks SMS inbound retentent, pourquoi l’ordre n’est pas garanti, et comment des handlers idempotents protègent l’ops prépayé et les macros support.

Le SMS outbound prend les tableaux de bord. L’inbound est là où STOP, HELP et les réponses clients atterrissent vraiment — et où des handlers naïfs inventent des tickets en double, des effets portefeuille doublés et des fantômes de conformité « on n’a jamais reçu le STOP ». Si votre chemin de réception suppose une livraison exactly-once et en ordre, vous échouerez au premier vrai outage.

IOSOR emballe le messaging inbound dans la même surface white-label prépayée que l’outbound : événements vérifiables, payloads brand-safe, sans vivre dans un portail ops étranger pour réconcilier une tempête de réponses.

Pourquoi les webhooks retentent

Chez la plupart des plateformes, les webhooks inbound promettent une livraison at-least-once avec retries, pas un ordre magique exactly-once.

Les trois modes d’échec à concevoir

Trait de retry Question acheteur Réponse saine
Backoff Les retries saturent-ils votre app ? Backoff exponentiel / avec jitter documenté
Budget Jusqu’à quand la plateforme retente ? Horizon de retry écrit
Signature Peut-on rejeter les contrefaçons ? Callbacks authentifiés
Vos 5xx Que se passe-t-il si vous êtes down 10 minutes ?

Idempotence : la propriété qui corrige les trois

L’inbound n’est pas exempt d’argent ni de side effects ops :

  • Les auto-replies peuvent débiter le portefeuille prépayé
  • La gestion STOP doit supprimer les futurs envois marketing
  • Les macros support qui ouvrent des tickets ne doivent pas en ouvrir trois pour trois POST

Checklist d’un handler de réception idempotent :

Ordre des événements : pourquoi « last write wins » est dangereux

Fausses hypothèses courantes :

  1. STOP arrive avant le prochain envoi marketing (il y a une course)
  2. Le DLR outbound arrive avant la réponse inbound (chemins indépendants)

STOP, HELP et autres mots-clés inbound exigent la même discipline

Compliance-critical inbound keywords deserve the strictest idempotency. A duplicated STOP must never double-log an opt-out or send two confirmations. A duplicated HELP must never fire two help messages to the same number in the same minute. Route keyword processing through the same dedupe table as regular inbound messages.

Démarrer avec IOSOR

Extrayez les journaux webhook inbound de la semaine et comptez les ID d’événement arrivés plus d’une fois. Rejouez un doublon et une paire hors ordre (failed, puis delivered). Le récepteur garde un effet : une ligne d’inbox, une écriture STOP, une touche portefeuille. Last-write-wins qui annule STOP rate. C’est l’idempotence à la réception et l’ordre des retries, pas la validation de signature ni un verrou de passerelle avant la file.

À retenir — IOSOR

Les webhooks inbound retentent. L’idempotence à la réception est la seule réponse sûre ; l’ordre n’est pas une promesse.

Faites : cléz l’événement et ignorez le jumeau. Ne faites pas : last-write-wins sur STOP ni deux débits pour le même événement.

Ce guide vous a-t-il aidé ?

Guides associés