--- title: "SMS-API oder SMPP: Welche Anbindung ist die richtige?" description: "SMS-API und SMPP im Vergleich: Sessions und Binds, Windowing, Durchsatz, Zustellberichte, Kodierung, TLS-Sicherheit, Betriebsaufwand und Migration." canonical: "https://omnichannels.ai/de/blog/sms-api-vs-smpp/" language: "de" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "sms api vs smpp" keywords: ["SMPP vs HTTP API", "REST SMS API", "SMPP Bind Transceiver", "SMPP Windowing Durchsatz", "SMPP Zustellbestätigung deliver_sm", "SMPP über TLS", "von HTTP auf SMPP migrieren", "SMPP 3.4"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 12 answer: "Nutzen Sie eine REST-SMS-API für Anwendungstraffic wie OTPs, Warnmeldungen und Benachrichtigungen sowie immer dann, wenn Sie auch WhatsApp, RCS oder andere Kanäle brauchen: Sie arbeitet zustandslos über HTTPS, ist leicht abzusichern und schnell implementiert. Nutzen Sie SMPP, wenn Sie hohe, gleichmäßige SMS-Volumen versenden, bereits SMPP-Clients betreiben oder SMS weiterverkaufen, denn ein dauerhafter Bind mit Windowing hält viele Nachrichten gleichzeitig in Bearbeitung. Viele Unternehmen betreiben beides über einen Account." takeaways: ["Eine REST-SMS-API sendet jede Nachricht als eigenständige HTTPS-Anfrage, während SMPP eine langlebige Session, den sogenannten Bind, offen hält und darüber binäre PDUs austauscht.", "Der SMPP-Durchsatz hängt vom Windowing ab: Ein Client, der vor jeder weiteren Nachricht auf die submit_sm_resp wartet, verschenkt den größten Teil der Verbindung.", "REST-Zustellstatus kommen an Ihrem Webhook an, SMPP-Zustellberichte dagegen als deliver_sm-PDUs in derselben Session, und jede muss quittiert werden.", "SMPP v3.4 hat keine eingebaute Verschlüsselung; produktive Binds sollten daher über TLS und von freigegebenen Quell-IP-Adressen laufen.", "SMPP transportiert nur SMS; eine Kombination aus REST für Multichannel-Traffic und SMPP für Massen-SMS ist daher ein verbreitetes langfristiges Design."] faq: - q: "Ist SMPP schneller als eine SMS-API?" a: "SMPP kann einen höheren Durchsatz halten, weil eine dauerhafte Session viele Nachrichten gleichzeitig transportiert, ohne für jede eine neue HTTP-Anfrage zu stellen. Bei einem einzelnen OTP ist der Unterschied selten spürbar, da die Zustellzeit beim Netzbetreiber überwiegt. Der Durchsatz beider Schnittstellen wird durch die Limits Ihres Accounts bestimmt; fragen Sie Ihren Anbieter daher nach den dokumentierten Limits, statt anzunehmen, dass SMPP immer schneller ist." - q: "Kann ich WhatsApp-Nachrichten über SMPP senden?" a: "Nein. SMPP ist ein Protokoll für SMS und verwandte Kurznachrichtendienste. WhatsApp, RCS, Messenger, Instagram, E-Mail und Push nutzen HTTP-APIs. Brauchen Sie mehrere Kanäle, verwenden Sie dafür eine REST-API und ergänzen Sie SMPP nur für hohe SMS-Volumen, falls nötig." - q: "Was ist ein SMPP-Bind?" a: "Ein Bind ist eine authentifizierte SMPP-Session zwischen Ihrem Client, der sogenannten ESME, und dem SMSC des Anbieters. Sie öffnen eine TCP- oder TLS-Verbindung und senden bind_transmitter, bind_receiver oder bind_transceiver mit Ihrer system_id und Ihrem Passwort. Ein Transceiver-Bind sendet Nachrichten und empfängt Zustellberichte in einer Session und ist die übliche Wahl." - q: "Ist SMPP sicher?" a: "SMPP v3.4 selbst verschlüsselt den Traffic nicht, und die Zugangsdaten werden in der Bind-Anfrage übertragen. Betreiben Sie produktive Binds über TLS, beschränken Sie Verbindungen auf registrierte Quell-IP-Adressen, speichern Sie system_id und Passwort als Secrets und rotieren Sie sie, wenn sie offengelegt wurden. Unverschlüsseltes SMPP über das öffentliche Internet sollten Sie vermeiden." - q: "Wie unterscheiden sich Zustellberichte bei SMPP und REST?" a: "Bei SMPP kommt eine Bestätigung als deliver_sm-PDU mit einem Text wie stat:DELIVRD an, und Ihr Client muss mit deliver_sm_resp antworten. Bei REST sendet der Anbieter ein JSON-Ereignis an Ihren Webhook, mit einem normalisierten Status wie DELIVERED oder FAILED. Beides ist asynchron: Eine angenommene Übermittlung ist nie ein Zustellnachweis." - q: "Wie lange dauert der Umstieg von einer SMS-API auf SMPP?" a: "Der Code ist nicht der langsame Teil, wenn Sie eine ausgereifte SMPP-Bibliothek nutzen. Länger dauert die Bereitstellung: Durchsatz und Zahl der Binds vereinbaren, Quell-IPs registrieren, Bestätigungen und Kodierung testen. Planen Sie eine Phase des Parallelbetriebs mit einem kleinen Teil des Traffics über SMPP ein, bevor Sie Volumen verlagern." sources: - title: "Short Message Peer to Peer Protocol Specification v3.4 (SMPP.org)" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "SMPP.org: Short Message Peer-to-Peer protocol resources" url: "https://smpp.org/" - title: "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3" url: "https://www.rfc-editor.org/rfc/rfc8446" - title: "RFC 9110: HTTP Semantics" url: "https://www.rfc-editor.org/rfc/rfc9110" - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)" url: "https://www.3gpp.org/dynareport?code=23040" --- # SMS-API oder SMPP: Welche Anbindung ist die richtige? Canonical: https://omnichannels.ai/de/blog/sms-api-vs-smpp/ Language: de Publisher: OmniChannels.ai by BroadNet Technologies 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](/de/blog/messaging-api-integration-guide/). ## 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. | | REST-SMS-API | SMPP v3.4 | |---|---|---| | Transport | HTTPS-Anfrage und -Antwort | Dauerhafte TCP-Session, im Produktivbetrieb in TLS gekapselt | | Zustand | Zustandslos; jede Anfrage steht für sich | Zustandsbehafteter Bind mit Sequenznummern und Keep-alives | | Authentifizierung | Bearer-Token im Header | `system_id` und Passwort im Bind, dazu IP-Allowlisting | | Kanäle | SMS und, bei einer Multichannel-API, WhatsApp, RCS und mehr | Nur SMS | | Durchsatzmodell | Anfragen pro Sekunde plus Bulk-Endpunkte | Nachrichten pro Sekunde und Bind, viele gleichzeitig per Windowing | | Zustellberichte | JSON-Webhook mit normalisierten Status | `deliver_sm`-PDU in der Session, textbasiertes Bestätigungsformat | | Kodierung | Ein Feld wie `messageType` (`TEXT` oder `UNICODE`) | `data_coding` (0 für GSM-7, 8 für UCS-2), UDH für lange Nachrichten | | Werkzeuge | Jeder HTTP-Client, SDKs, OpenAPI | Eine SMPP-Client-Bibliothek | | Betriebsaufwand | Gering | Mittel: Verbindungen, Wiederverbindung, Windows, Bestätigungen | | Ideal für | Anwendungen, OTP, Benachrichtigungen, Multichannel | Aggregatoren, Reseller, Großversender mit SMPP-Erfahrung | ## 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: ```bash 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](/developers/sms/). 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](/developers/smpp/) 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](/developers/errors-and-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](/developers/webhooks/). 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: ```text 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: | SMPP `stat` | Bedeutung | Normalisierter Status | |---|---|---| | `ACCEPTD` | Angenommen, Zwischenstatus | SENT | | `DELIVRD` | An das Endgerät zugestellt | DELIVERED | | `UNDELIV` | Nicht zustellbar | FAILED | | `EXPIRED` | Gültigkeitsdauer abgelaufen | FAILED | | `REJECTD` | Abgelehnt, etwa wegen eines gesperrten Absenders | REJECTED | | `DELETED` | Vor der Zustellung gelöscht | FAILED | | `UNKNOWN` | Keine Statusinformation | Letzten bekannten Status beibehalten | 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](/de/blog/message-delivery-status-explained/). ## 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](/de/blog/sms-character-limits-unicode-arabic/). ## 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. ```text host: port: bind type: transceiver system_id: password: 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](/developers/smpp/) oder dem [Quickstart](/developers/quickstart/), oder sehen Sie sich die [Entwicklerübersicht](/developers/) an.