IOSOR

IOSOR Wissen

Inbound-SMS-Webhooks: Retries, Ereignisreihenfolge und Idempotenz beim Empfang

B2B-Guide für den Empfangspfad: wie Inbound-SMS-Webhooks retrien, warum Reihenfolge nicht garantiert ist und wie idempotente Handler Prepaid-Ops und Support-Makros schützen.

Jeder Handler für eingehende SMS wird früher oder später mit doppelten Webhooks, verdrehten Ereignisreihenfolgen und mehrfach verarbeiteten Stopp-Anfragen konfrontiert. Das ist kein Fehler des Providers, sondern das normale Verhalten von At-Least-Once-Zustellsystemen. Um Datenkorruption zu vermeiden, muss Ihr Empfangsendpunkt diese Events mithilfe von eindeutigen Nachrichten-IDs idempotent verarbeiten und doppelte Aufrufe konsequent abfangen.

Warum Webhooks überhaupt retrien

Bei den meisten Plattformen versprechen Inbound-Webhooks at-least-once mit Retries, keine magische exactly-once-Ordnung.

  • Doppelte POSTs desselben logischen Events
  • Späte Ankünfte nach Timeout
  • Gelegentliche Out-of-Order-Lieferungen relativ zu einem anderen Eventtyp

Produkt-UX kann sich dennoch geordnet anfühlen, wenn Ihr Store einen deterministischen Merge anwendet — nicht wenn Sie hoffen, dass die Leitung nie glitcht.

Die drei Failure Modes, für die Sie designen müssen

Retry-Merkmal Käuferfrage Gesunde Antwort
Backoff Stampeden Retries Ihre App? Exponentielles / jittered Backoff dokumentiert
Budget Wann hört die Plattform auf? Geschriebener Retry-Horizont
Signatur Können Fälschungen abgelehnt werden? Authentifizierte Callbacks
Ihre 5xx Was wenn Sie 10 Minuten down sind? Retries laufen weiter; Sie holen idempotent auf .

Behandeln Sie eine Spitze doppelter Lieferungen als Beweis, dass Retry funktioniert — nicht als Incident, sofern Ihre Side Effects idempotent sind.

Idempotenz: die eine Eigenschaft, die alle drei behebt

Inbound ist nicht frei von Geld- und Ops-Side-Effects:

  • Auto-Replies können das Prepaid-Wallet belasten
  • STOP-Handling muss künftige Marketing-Sends unterdrücken
  • Support-Makros, die Tickets öffnen, dürfen nicht drei Tickets für drei POSTs öffnen

Checkliste für einen idempotenten Empfangs-Handler:

  1. Inbound-Event-ID vor Side Effects persistieren
  2. Duplikate mit dem vorherigen Outcome short-circuiten
  3. Auto-Reply-Sends mit eigener Idempotency-Key versehen
  4. Korrelation loggen: Inbound-ID → Wallet-Zeile → Reply-ID

Ereignisreihenfolge: warum „last write wins“ gefährlich ist

Häufige Fehlangnahmen:

  1. STOP kommt vor dem nächsten Marketing-Send (Race existiert)
  2. Outbound-DLR kommt vor Inbound-Reply (unabhängige Pfade)
  3. „First POST wins“ ohne dauerhaften Event-Schlüssel

Bauen Sie ein Empfangs-Ledger keyed by dauerhafter Event-/Message-ID. Wenden Sie Business-Regeln als State Transitions auf diesem Ledger an — nicht als „Side Effect auf jedem HTTP-200-Pfad“.

STOP, HELP und andere Inbound-Keywords brauchen dieselbe Disziplin

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.

Mit IOSOR starten

In der Konsole: Inbound SMS webhook retries stay idempotent; no double MO side-effects.. Benennen Sie Owner und Gates vor dem Scale.

Verwandt: inbound autoreply loop wallet drain inbound carrier latency webhook time.

IOSOR-Kernpunkte

Ops-Disziplin für den Dienst—kein Brochure.

Tun: name owner + gate. Nicht: skip the gate.

War dieser Leitfaden hilfreich?

Verwandte Leitfäden