SMS-API oder SMPP: Welche Anbindung ist die richtige?

Dieser Leitfaden richtet sich an Entwickler und technische Leads, die entscheiden, wie sie sich mit einem SMS-Anbieter verbinden: über eine HTTP/REST-SMS-API, über SMPP oder über beides. Er erklärt, wie sich beide auf der Leitung und im Betrieb tatsächlich unterscheiden, damit Sie für jede Art von Traffic die richtige Schnittstelle wählen und eine Migration planen können, wenn Ihre erste Wahl nicht mehr ausreicht.

Einen breiteren Überblick über Integrationsmuster einschließlich Webhooks und Idempotenz bietet unser Leitfaden zur Integration einer Messaging-API.

Was unterscheidet eine SMS-API von SMPP?

Eine REST-SMS-API sendet jede Nachricht als separate HTTPS-Anfrage und liefert eine Nachrichten-ID zurück. SMPP (Short Message Peer-to-Peer) hält eine langlebige, authentifizierte Session offen und tauscht darüber in beide Richtungen binäre Nachrichten aus, sogenannte PDUs. REST ist auf Einfachheit optimiert, SMPP auf dauerhaft hohe SMS-Volumen.

Wie funktioniert eine REST-SMS-API?

Sie senden einen HTTPS-POST mit Token und JSON-Body, und der Anbieter antwortet mit einer ID. Jede Anfrage ist unabhängig; Sie können also von jedem Server, jeder Funktion und jedem Container senden, ohne eine Verbindung verwalten zu müssen.

Ein typischer Versand mit unserer API sieht so aus:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

Die Antwort lautet 200 OK mit der Nachrichten-ID als reinem Text. Der endgültige Status kommt später an Ihrem Webhook an, als SUBMITTED, SENT, DELIVERED, FAILED oder REJECTED. Feldnamen und Optionen finden Sie in der SMS-API-Referenz.

Stärken von REST:

• Vertraute Werkzeuge: jede Sprache, jeder HTTP-Client, Standard-Statuscodes nach RFC 9110.
• Einfache Absicherung: durchgängig TLS und ein Token im Authorization-Header.
• Bulk ohne Verbindungen: eine Empfängerdatei in einer Anfrage hochladen, statt eine Session zu öffnen.
• Eine API für viele Kanäle: Dasselbe Muster sendet WhatsApp-Vorlagen oder RCS-Karten.

Grenzen von REST: Jede Nachricht oder jeder Batch kostet einen HTTP-Roundtrip, und Sie stoßen eher an ein Limit für Anfragen pro Sekunde als an ein Limit des Netzbetreibers. Für die meisten Anwendungsfälle spielt das nie eine Rolle.

Wie funktioniert SMPP?

SMPP ist ein binäres Protokoll, definiert durch die Spezifikation SMPP v3.4, veröffentlicht vom SMPP Developers Forum (später SMS Forum) und bis heute die am weitesten verbreitete Version. Ihr System, die sogenannte ESME (External Short Message Entity), verbindet sich mit dem SMSC (Short Message Service Centre) des Anbieters und öffnet eine Session, den sogenannten Bind.

Bind-Typen

• Transmitter (TX) mit bind_transmitter: nur Nachrichten senden.
• Receiver (RX) mit bind_receiver: nur Zustellberichte und eingehende Nachrichten empfangen.
• Transceiver (TRX) mit bind_transceiver: beides in einer Session. Das ist die übliche Wahl.

Lebenszyklus einer Session

1. Öffnen Sie eine TLS-Verbindung zu Host und Port, die Ihr Anbieter Ihnen nennt.
2. Senden Sie bind_transceiver mit Ihrer system_id und Ihrem Passwort und warten Sie auf eine Antwort mit command_status 0.
3. Senden Sie Nachrichten mit submit_sm. Jede submit_sm_resp liefert eine message_id zurück.
4. Empfangen Sie Zustellberichte als deliver_sm und beantworten Sie jede mit deliver_sm_resp.
5. Senden Sie im Leerlauf regelmäßig enquire_link, damit beide Seiten wissen, dass die Session aktiv ist.
6. Beenden Sie mit unbind und warten Sie auf unbind_resp.

Jede PDU trägt eine Sequenznummer, und Antworten tragen dieselbe Nummer; so ordnen Sie eine submit_sm_resp der gesendeten Nachricht zu. Unsere SMPP-Dokumentation beschreibt jeden Schritt mit unseren Einstellungen.

Was ist SMPP-Windowing und warum ist es wichtig?

Windowing bedeutet, mehrere submit_sm-PDUs zu senden, bevor deren Antworten zurückkommen. Die Zahl der unbestätigten PDUs, die gleichzeitig unterwegs sein dürfen, ist das Window. Es ist der Hauptgrund, warum SMPP einen höheren Durchsatz hält als HTTP mit einer Anfrage nach der anderen.

Bei einem Window von 1 sendet Ihr Client eine Nachricht, wartet einen vollen Roundtrip auf die Antwort und sendet dann die nächste. Der Durchsatz wird dann durch die Netzwerklatenz begrenzt, nicht durch Ihre vereinbarte Rate. Mit einem größeren Window bleibt die Verbindung ausgelastet, während die Antworten eintreffen.

Faustregeln:

• Nutzen Sie die mit Ihrem Anbieter vereinbarte Window-Größe und überschreiten Sie sie nie; zusätzliche PDUs können abgelehnt werden.
• Halten Sie die vereinbarte Rate pro Bind ein. Erhalten Sie ESME_RTHROTTLED, drosseln Sie und wiederholen Sie mit Backoff.
• Verfolgen Sie offene Sequenznummern, damit Sie bei einem Verbindungsabbruch nicht den Überblick verlieren, welche Nachrichten angenommen wurden.
• Skalieren Sie mit mehr Binds, bis zu der für Ihren Account vereinbarten Zahl, statt mit einem immer größeren Window.

Die Standardlimits unserer REST-API und SMPP-Binds sind unter Fehler und Limits aufgeführt; die Limits Ihres Accounts werden bei der Bereitstellung des Zugangs bestätigt.

Wie unterscheiden sich Zustellberichte?

Bei REST sendet der Anbieter ein JSON-Ereignis an Ihren Webhook. Bei SMPP kommt die Bestätigung als deliver_sm-PDU in der Session an, mit gesetztem Bestätigungsbit in esm_class. Beides ist asynchron; weder 200 OK noch submit_sm_resp bedeutet, dass das Endgerät die Nachricht erhalten hat.

Die Spezifikation SMPP v3.4 nennt das Textformat der Bestätigung als Beispiel und überlässt das genaue Format dem SMSC-Hersteller, doch die meisten Anbieter halten sich daran:

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

Nutzen Ihre Systeme beide Schnittstellen, bilden Sie die SMPP-Zustände auf ein gemeinsames Statusmodell ab. Eine typische Zuordnung:

Zwei praktische Unterschiede sind wichtiger als das Format:

• Quittierung. Ein SMPP-Client muss jede deliver_sm beantworten. Nicht quittierte Bestätigungen werden erneut gesendet und können den Bind verlangsamen. Aus demselben Grund muss ein Webhook-Handler schnell mit 2xx antworten.
• Wiederherstellung. Ist Ihr SMPP-Client getrennt, warten Bestätigungen auf den nächsten Bind oder verfallen womöglich in der Warteschlange des Anbieters. Bei REST bietet ein Anbieter unter Umständen eine erneute Zustellung von Bestätigungen für einen Zeitraum an. Fragen Sie, wie beides funktioniert.

Mehr zur Bedeutung der einzelnen Status lesen Sie unter Zustellstatus von Nachrichten erklärt.

Wie wird die Kodierung gehandhabt?

Beide Schnittstellen müssen zwischen GSM-7 und Unicode wählen, und beide teilen lange Nachrichten in Segmente auf. Der Unterschied liegt darin, wer die Arbeit erledigt.

• REST: Sie setzen ein Feld wie messageType auf TEXT oder UNICODE, und die Plattform segmentiert lange Nachrichten. Unsere API bietet zudem POST /sms/identify, um Zeichen und Segmente vorab zu zählen.
• SMPP: Sie setzen data_coding (0 für das GSM-7-Standardalphabet, 8 für UCS-2) und kodieren die Bytes selbst. Bei langen Nachrichten fügen Sie entweder jedem Teil einen User Data Header hinzu und setzen esm_class auf 0x40, oder Sie senden den gesamten Text im Feld message_payload, sofern Ihr Anbieter das freischaltet.

Nach 3GPP TS 23.040 transportiert eine einzelne SMS 140 Oktette: 160 GSM-7-Zeichen oder 70 UCS-2-Zeichen, bzw. 153 oder 67 pro Teil, wenn der Header hinzukommt. Ein einziger arabischer Buchstabe oder ein Emoji macht die gesamte Nachricht zu Unicode. Kodierungsfehler sind der häufigste Fehler bei SMPP-Integrationen; testen Sie daher mit Arabisch, Emoji und langen Texten. Siehe unseren Leitfaden zu Zeichenlimits.

Wie unterscheiden sich die Sicherheitsmodelle?

REST stützt sich auf TLS und ein Bearer-Token pro Anfrage. SMPP v3.4 hat keine eigene Verschlüsselung und überträgt die Zugangsdaten im Bind; es hängt also von den Transport- und Netzwerkkontrollen drumherum ab.

Für SMPP:

• Nutzen Sie TLS (TLS 1.3 ist in RFC 8446 definiert) oder eine private Verbindung; niemals unverschlüsseltes SMPP über das öffentliche Internet.
• Registrieren Sie Quell-IP-Adressen, damit sich nur Ihre Server binden können.
• Speichern Sie system_id und Passwort als Secrets, getrennt je Umgebung, und rotieren Sie sie, wenn sie offengelegt wurden.
• Überwachen Sie fehlgeschlagene Binds, die auf Fehlkonfiguration oder Missbrauch von Zugangsdaten hindeuten können.

Für REST:

• Halten Sie das Token ausschließlich auf Servern, niemals in mobilen Apps oder Browsercode.
• Meiden Sie ältere HTTP-Schnittstellen, die Benutzername und Passwort in der URL übergeben, wo sie in Logs landen.
• Schützen Sie den Webhook mit HTTPS, einem nicht erratbaren Pfad und strenger Validierung des Inhalts.

Welchen Betriebsaufwand verursacht jede Option?

REST verursacht fast keinen Betriebsaufwand: Anfragen sind entweder erfolgreich oder liefern einen Fehler, den Sie wiederholen können. SMPP bringt eine dauerhaft laufende Komponente mit, die Sie überwachen und pflegen müssen.

Ein SMPP-Client braucht:

1. Verbindungsmanagement mit Wiederverbindung über Backoff und Jitter statt einer engen Schleife;
2. Keep-alives und die Erkennung stiller, halb offener Verbindungen;
3. Window- und Ratensteuerung pro Bind;
4. Nachverfolgung der Sequenzen und Abgleich nach Verbindungsabbrüchen;
5. Quittierung und Speicherung der Bestätigungen;
6. Logik für Kodierung und Verkettung;
7. Überwachung von Bind-Status, Durchsatz, Drosselungsfehlern und Verzögerung der Bestätigungen.

Ausgereifte Open-Source-Bibliotheken übernehmen das Protokoll, doch Ihr Team bleibt für das Verhalten drumherum verantwortlich, auch während eines Wartungsfensters des Anbieters um 3 Uhr morgens.

Wann sollten Sie welche Option nutzen?

Nutzen Sie REST, sofern Sie keinen klaren Grund haben, SMPP hinzuzunehmen.

Wählen Sie eine REST-SMS-API, wenn

• Sie OTPs, Warnmeldungen, Benachrichtigungen oder Kampagnen aus Anwendungen versenden;
• Sie neben SMS auch WhatsApp, RCS oder andere Kanäle brauchen;
• Ihre Plattform auf Serverless-Funktionen oder kurzlebigen Containern läuft;
• Ihr Team keine SMPP-Erfahrung hat und sie auch nicht aufbauen muss.

Wählen Sie SMPP, wenn

• Sie hohe, gleichmäßige SMS-Volumen versenden und an die Grenzen von REST gestoßen sind;
• Sie bereits ein SMPP-Gateway oder eine Messaging-Plattform betreiben;
• Sie Aggregator, Carrier oder Reseller sind und den SMS-Traffic Ihrer eigenen Kunden anbinden;
• Sie dasselbe Protokoll über mehrere Upstream-Anbieter hinweg brauchen.

Wie sieht ein hybrides Setup aus?

Viele Unternehmen nutzen beides über einen Account: REST für Multichannel- und Anwendungstraffic, SMPP für Massen-SMS. Die Falle besteht darin, am Ende zwei Zustellmodelle zu haben.

• Routen Sie nach Anwendungsfall, nicht zufällig: zum Beispiel OTP und WhatsApp über REST, Kontoauszüge per Massen-SMS über SMPP.
• Normalisieren Sie die Status aus Webhooks und deliver_sm in eine gemeinsame Tabelle mit der Nachrichten-ID als Schlüssel.
• Verwenden Sie eine einheitliche Richtlinie für Absenderkennungen (Sender-IDs), denn Registrierungen gelten unabhängig von der genutzten Schnittstelle.
• Berichten Sie gemeinsam, damit eine auf beide Schnittstellen verteilte Kampagne ein einziges Ergebnis zeigt.

Wie migrieren Sie von einer SMS-API zu SMPP?

Gehen Sie schrittweise vor, mit beiden Schnittstellen im Betrieb, und messen Sie, bevor Sie Volumen verlagern.

1. Bestätigen Sie den Bedarf: Dokumentieren Sie das Volumen oder den Durchsatz, den REST nicht schafft.
2. Beantragen Sie die Bereitstellung: Teilen Sie Zielländer, Absenderkennungen, erwarteten Spitzendurchsatz und Quell-IP-Adressen mit.
3. Wählen Sie eine ausgereifte Client-Bibliothek in Ihrem Stack und kapseln Sie sie in Ihre eigene Sendeschnittstelle.
4. Bauen Sie zuerst die Verarbeitung der Bestätigungen, abgebildet auf dasselbe Statusmodell wie Ihre Webhooks.
5. Testen Sie die Kodierung: GSM-7, Arabisch, Emoji und mehrteilige Nachrichten auf echten Endgeräten.
6. Testen Sie Fehlerfälle: Verbindung mitten im Senden trennen, Drosselung auslösen und den Abgleich prüfen.
7. Betreiben Sie beides parallel: Verlagern Sie einen kleinen Teil einer Traffic-Art auf SMPP und vergleichen Sie Zustellung und Bestätigungen.
8. Verlagern Sie das Volumen schrittweise und behalten Sie REST als Fallback-Pfad.

Eine beispielhafte Bind-Konfiguration sieht so aus. Host, Port und Limits sind Platzhalter; die echten Werte erhalten Sie mit Ihren bereitgestellten Zugangsdaten.

host:                 <wird mit Ihrem Bind bereitgestellt>
port:                 <TLS-Port, wird mit Ihrem Bind bereitgestellt>
bind type:            transceiver
system_id:            <Ihre system_id>
password:             <Ihr Passwort>
system_type:          (leer, sofern nicht anders angegeben)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (alphanumerische Absender-ID)
dest_addr_ton/npi:    1 / 1   (internationale Nummer)
registered_delivery:  1       (Zustellberichte anfordern)
data_coding:          0 (GSM-7) oder 8 (UCS-2)
enquire_link:         alle 30 Sekunden im Leerlauf
window:               wie für Ihren Account vereinbart

Praxisbeispiel: ein regionaler Händler ergänzt SMPP für Kontoauszüge

„Souq Rafiq“ (fiktiv), ein Onlinehändler in den VAE, Ägypten und Jordanien, versendet OTPs und Bestellupdates über eine REST-API und WhatsApp-Vorlagen über dieselbe API. Die monatlichen Kontoauszüge, die per SMS an den gesamten Kundenstamm gehen, sind so weit gewachsen, dass der REST-Job länger dauert, als dem Unternehmen lieb ist.

• Entscheidung: OTP, Bestellupdates und WhatsApp bleiben auf REST. Die SMS mit den monatlichen Kontoauszügen wandern auf einen SMPP-Transceiver-Bind.
• Bereitstellung: Das Team registriert zwei Quell-IPs, bestätigt die Absenderkennungen je Land und vereinbart Durchsatz und Zahl der Binds.
• Umsetzung: Ein kleiner SMPP-Dienst nutzt eine Open-Source-Bibliothek, schreibt Bestätigungen in dieselbe Statustabelle wie der Webhook und stellt dieselbe interne Sendeschnittstelle bereit wie der REST-Pfad.
• Tests: Arabische Kontoauszüge werden auf mehreren Endgeräten als UCS-2 mit korrekter Verkettung bestätigt.
• Rollout: Ein Land wechselt zuerst. Nach dem Vergleich von Zustellung und Bestätigungszeiten mit der REST-Basis folgen die anderen Länder, wobei REST als Fallback erhalten bleibt.

Häufige Fehler

• SMPP aus Prestigegründen wählen. Wenn REST Ihr Volumen bewältigt, bringt SMPP nur Mehraufwand.
• Mit einem Window von 1 arbeiten und dann den Anbieter für den geringen Durchsatz verantwortlich machen.
• deliver_sm nicht quittieren, was erneut gesendete Bestätigungen und Drosselung verursacht.
• Nach einem Verbindungsabbruch in einer engen Schleife neu verbinden, was wie ein Angriff aussehen kann.
• short_message und message_payload in einer PDU mischen, was Längenfehler verursacht.
• Unverschlüsseltes SMPP über das Internet, das Zugangsdaten und Inhalte offenlegt.
• Zwei Statusmodelle in einem hybriden Setup, sodass die Berichte voneinander abweichen.
• Grenzen: Dieser Leitfaden beschreibt gängige Praxis. Window-Größen, Raten, TLS-Ports und Details zu Bestätigungen unterscheiden sich je Anbieter und Account; lassen Sie sie bei der Bereitstellung bestätigen.

So unterstützt OmniChannels.ai

OmniChannels.ai bietet beides. Die REST-API unter https://api.broadnet.me nutzt ein Bearer-Token und deckt SMS zusammen mit WhatsApp, RCS, Messenger, Instagram, Telegram, E-Mail und Push ab; Zustellstatus werden in einem einheitlichen Format an Ihren Webhook gesendet. Für hohe SMS-Volumen werden SMPP-3.4-Binds über TLS pro Account bereitgestellt, mit freigegebenen Quell-IPs, und nutzen dieselben SMS-Routen über BroadNets direkte Betreiberanbindung. Reseller und Wholesale-Partner können dedizierte Binds erhalten. Starten Sie mit der SMPP-Dokumentation oder dem Quickstart, oder sehen Sie sich die Entwicklerübersicht an.