Zwei Webhook-Payloads tragen Messaging-Events. Ein Delivery-Status-Event (DLR) meldet das Ergebnis einer Nachricht — message_id, ein Status-Enum (accepted, delivered, undelivered, expired, rejected), einen Fehlergrund und Zeitstempel. Ein Inbound-Event (MO) meldet eine Nachricht, die ein Teilnehmer an Sie gesendet hat. Beide sind die HTTP-Entsprechungen von SMPP-deliver_sm-Receipts und mobile-originated-Nachrichten.
- Ihre AnwendungVersand über REST API oder SMPP
- BroadNet-PlattformValidiert, routet und fakturiert jede Nachricht
- SMSC des BetreibersDirekte Operator-Anbindung
- Endgerät des AbonnentenDie Nachricht wird zugestellt
Zwei Event-Familien: Status und Inbound
Eine Messaging-Plattform emittiert zwei grundverschiedene Callbacks. Ein Delivery-Status-Event (DLR, Zustellquittung) ist die asynchrone Nachfolge einer von Ihnen gesendeten Nachricht: es sagt Ihnen, was ihr schließlich im Operator-Netz widerfahren ist. Ein Inbound-Event (MO, mobile-originated) ist unaufgefordert — eine Nachricht, die ein Teilnehmer an eine Ihrer Nummern gesendet hat, oder eine Antwort auf eine Kampagne. Sie teilen sich Transport und Signierung des webhook, aber ihre Schemata und ihre Bedeutung unterscheiden sich, daher verzweigt ein robuster Consumer anhand eines Event-Typ-Diskriminators, bevor er den Rest parst. Beide sind der Ausdruck auf HTTP-Ebene von Dingen, die SMPP als deliver_sm-PDUs zustellt: ein Receipt-Flag unterscheidet auf dem Wire ein DLR von einem MO, und dieselbe Unterscheidung ist über HTTP ein explizites Event-Feld.
Delivery-Status-Payload (DLR)
Ein Delivery-Status-Payload korreliert über die serverseitig vergebene message_id mit dem ursprünglichen Versand und meldet einen Status aus einer kleinen Enumeration, dazu den Grund und die Zeitstempel, mit denen Sie Latenz messen und die Abrechnung abgleichen können. Das Status-Enum ist der Kern: es unterscheidet einen Zwischenzustand accepted/enroute von den Endzuständen und trennt ein positives delivered von den mehreren Arten, auf die eine Nachricht scheitern kann. Negative Endzustände tragen einen Fehlercode und einen menschenlesbaren Grund, sodass ein Consumer entscheiden kann, ob das Ziel dauerhaft schlecht ist (unterdrücken) oder der Fehlschlag transient war (gefahrlos erneut senden). Zeitstempel umfassen typischerweise, wann die Plattform die Nachricht angenommen hat und wann der Endstatus eingetreten ist.
{
"event": "message.delivered",
"message_id": "01HZY8Q3M6",
"to": "+15551234567",
"status": "delivered",
"error": null,
"reason": null,
"submitted_at": "2026-07-19T09:15:22Z",
"done_at": "2026-07-19T09:15:25Z",
"sequence": 3
}Die Delivery-Status-Enumeration
Die Standardisierung der Statuswerte ist das, was einem Consumer erlaubt, jeden Operator zu behandeln, denn rohe Netzantworten variieren enorm. Ein kanonisches Enum bildet sie auf eine Handvoll Zustände mit klarer Semantik ab: ob der Zustand terminal ist und ob er ein Erfolg ist. Zwischenzustände (accepted, enroute) können durch ein späteres Event für dieselbe message id ersetzt werden — genau deshalb tragen Payloads eine Sequenz oder einen Zeitstempel, und deshalb wenden Consumer die Selbstordnungs-Regel aus der Webhook-Zuverlässigkeit an: ein spätes accepted darf niemals ein früheres delivered überschreiben.
| status | Terminal | Bedeutung |
|---|---|---|
| accepted | No | Die Plattform hat die Nachricht zur Zustellung angenommen |
| enroute | No | Dem Netzbetreiber übergeben, Zustellbestätigung ausstehend |
| delivered | Ja | Zustellung an das Mobiltelefon bestätigt |
| undelivered | Ja | Der Betreiber konnte nicht zustellen (siehe Fehler/Grund) |
| expired | Ja | Gültigkeitsdauer vor der Zustellung abgelaufen |
| rejected | Ja | Abgelehnt (ungültige Nummer, Absender blockiert, Spamfilter) |
| unknown | Ja | Der Betreiber hat keinen definitiven Endstatus zurückgegeben |
Inbound-Nachrichten-Payload (MO)
Ein Inbound-Event trägt den Nachrichteninhalt plus das Routing, das zum Antworten und zum Korrelieren einer Konversation nötig ist. Die kritischen Felder sind from (die MSISDN des Teilnehmers in E.164), to (die Nummer oder der Short-/Long-Code, an die sie geschrieben haben) und der text; daneben eine Message-ID für die eingehende Nachricht selbst, ein received-Zeitstempel und — weil eingehende SMS denselben Codierungs- und Segmentierungsregeln unterliegt wie ausgehende — die encoding sowie, bei einer mehrteiligen Nachricht, die Concatenation-Referenz und die Part-Indizes, damit der Consumer den vollständigen Text wieder zusammensetzen kann. Inbound-Events treiben Keyword-Kampagnen, Zwei-Wege-Konversationen und STOP/HELP-Compliance-Flows an.
{
"event": "message.inbound",
"message_id": "01HZY8R7T0",
"from": "+15551234567",
"to": "44160",
"text": "STOP",
"encoding": "GSM7",
"received_at": "2026-07-19T09:20:11Z",
"concat": { "ref": null, "part": 1, "total": 1 }
}Event-Typ-Taxonomie
Über DLR und MO hinaus emittiert eine Plattform Lifecycle- und Konto-Events, und ein einheitliches Benennungsschema — ein Punkt-getrennter resource.action-String — lässt einen Consumer sie sauber abonnieren und routen. Delivery-Status-Events sind Varianten von message.<status>; das Inbound-Event ist message.inbound. Die Gruppierung nach dem Ressourcen-Präfix bedeutet, dass ein Consumer message.* für alles rund um eine Nachricht matchen und andere Präfixe für Konto- oder Nummern-Events reservieren kann. Jedes Event sollte außerdem eine stabile Event-ID (verwendet als Signatur-Nonce und Dedup-Schlüssel) und den Typ-String tragen, sodass der Diskriminator und der Idempotenz-Schlüssel stets vorhanden sind.
| Ereignistyp | Familie | Ausgelöst, wenn |
|---|---|---|
| message.accepted | Status (DLR) | Nachricht zur Zustellung angenommen |
| message.delivered | Status (DLR) | Zustellung an das Mobiltelefon bestätigt |
| message.undelivered | Status (DLR) | Der Betreiber konnte nicht zustellen |
| message.expired | Status (DLR) | Gültigkeitszeitraum abgelaufen |
| message.rejected | Status (DLR) | Nachricht wurde upstream abgelehnt |
| message.inbound | Inbound (MO) | Ein Teilnehmer hat Ihnen eine Nachricht gesendet |
Abbildung von HTTP-DLR auf SMPP-deliver_sm
Der HTTP-Delivery-Status-Callback und die SMPP-Zustellquittung sind dieselbe Information in zwei Codierungen, und eine Plattform, die REST und SMPP überbrückt, übersetzt zwischen ihnen. Auf SMPP kommt eine Quittung als deliver_sm-PDU an, deren esm_class sie als Receipt markiert; ihr short-message-Feld trägt eine Text-Quittung mit id-, stat- und err-Feldern, und die message_state-TLV trägt den numerischen Zustand. Der HTTP-DLR hebt diese in JSON: der SMPP-stat-Token wird auf das kanonische Status-Enum abgebildet, der err-Wert auf das error-Feld und die submit-/done-Zeiten der Quittung auf submitted_at/done_at. Dieses Mapping zu verstehen ist das, was einem einzigen Zustell-Codepfad erlaubt, beide Transporte zu bedienen; das SMPP-Quittungsformat und die deliver_sm-PDU sind ausführlich in der SMPP-Referenz dokumentiert.
| Feld der SMPP-Zustellbestätigung | HTTP DLR Feld | Hinweis |
|---|---|---|
| id (Zustellbestätigung) | message_id | Korreliert mit dem ursprünglichen submit_sm / POST |
| stat (DELIVRD/UNDELIV/EXPIRED/REJECTD) | status | Token werden auf die kanonische Enumeration abgebildet |
| err | error | Betreiber-/Netzwerkfehlercode |
| message_state TLV | Status (numerische Zuordnung) | Numerischer SMPP-Status hinter dem Token |
| Sendedatum / Erledigt am | submitted_at / done_at | Zeitstempel für Latenz und Abgleich |
Häufig gestellte Fragen
Was steht in einem Delivery-Status-Webhook-Payload (DLR)?
Die serverseitig vergebene message_id, die es mit Ihrem Versand korreliert, ein Status aus einem kanonischen Enum (accepted, enroute, delivered, undelivered, expired, rejected, unknown), ein Fehlercode und ein menschenlesbarer Grund für Fehlschläge sowie Zeitstempel dafür, wann die Nachricht eingereicht wurde und wann der Endstatus eintrat.
Wie unterscheidet sich ein Inbound-Event (MO) von einem DLR?
Ein DLR ist das asynchrone Ergebnis einer von Ihnen gesendeten Nachricht. Ein Inbound-Event (MO) ist unaufgefordert — eine Nachricht, die ein Teilnehmer an Ihre Nummer gesendet hat, oder eine Antwort auf eine Kampagne — und trägt from, to, den text, encoding und, bei mehrteiligen Nachrichten, Concatenation-Felder. Sie teilen Transport und Signierung, haben aber verschiedene Schemata, daher verzweigen Consumer zuerst nach dem Event-Typ.
Warum das Delivery-Status-Enum standardisieren?
Weil rohe Operator-Antworten enorm variieren. Sie auf ein kleines kanonisches Enum mit klarer Terminal-und-Erfolg-Semantik abzubilden, lässt einen Consumer jeden Operator einheitlich behandeln und erlaubt Ihnen, allein aus dem Status zu entscheiden, ob Sie ein schlechtes Ziel unterdrücken, einen transienten Fehler erneut senden oder eine bestätigte Zustellung verbuchen.
Wie verhindere ich, dass ein spätes ‚accepted‘ ein früheres ‚delivered‘ überschreibt?
Mit den Selbstordnungs-Feldern. DLR-Payloads tragen einen Zeitstempel und oft eine Sequenznummer; der Consumer vergleicht sie mit dem zuletzt für diese message id verbuchten Zustand und verwirft jedes Event, das älter ist als das bereits Vorhandene, sodass ein Zwischenzustand außer Reihenfolge nie einen Endzustand überschreibt.
Wie wird ein HTTP-DLR auf ein SMPP-deliver_sm-Receipt abgebildet?
Sie tragen dieselbe Information. Auf SMPP ist die Quittung eine deliver_sm-PDU, in esm_class markiert, mit id-, stat- und err-Feldern und einer message_state-TLV. Der HTTP-DLR bildet stat auf das Status-Enum ab, err auf error und die Quittungs-Zeitstempel auf submitted_at/done_at — sodass ein einziger Zustell-Codepfad beide Transporte bedienen kann.
Welche Felder erlauben mir, eine mehrteilige eingehende SMS wieder zusammenzusetzen?
Die Concatenation-Felder: eine Referenz, die die Teile verbindet, der Part-Index und die Gesamtzahl. Weil eingehende SMS denselben Codierungs- und Segmentierungsregeln wie ausgehende folgt, kommt eine lange eingehende Nachricht als mehrere MO-Events an, die der Consumer mithilfe dieser Felder der Reihe nach zusammenfügt.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)