SMPP vs. HTTP-(REST-)API für SMS.
BroadNet bietet sowohl eine HTTP-(REST-)SMS-API als auch SMPP-Binds an; die richtige Wahl hängt von Ihrem dauerhaften Volumen und Ihrer Integrationsweise ab. Eine REST SMS API ist das richtige Werkzeug für nahezu jedes moderne Engineering-Team — sie ist firewallfreundlich, sprachagnostisch und leicht zu integrieren. BroadNet setzt keine festen Ratenlimits pro Konto für REST; SMPP ist das richtige Werkzeug, wenn Sie dauerhaft mehrere hundert Nachrichten pro Sekunde senden oder persistente Binds benötigen, oder für jede Last, die binäre Effizienz und volle DLR-Semantik braucht. Die meisten BroadNet-Kunden beginnen mit REST und fügen eine SMPP-Anbindung hinzu, wenn ihr Volumen es rechtfertigt.
12 Zeilen. Ohne Schönrederei.
Dieselben Kriterien, beide Spalten. Wo eine Zeile wirklich vom Anwendungsfall abhängt, sagt die Tabelle das. Wo eine Seite klar das bessere Werkzeug ist, sagt die Tabelle auch das.
| Fähigkeit | Spalte A SMS API (REST) HTTPS / JSON | Spalte B SMPP Short Message Peer-to-Peer 3.4 / 5.0 |
|---|---|---|
Protokoll | HTTPS POST + JSON | Binäres TCP, persistente Sitzung |
Standard-Port | 443 (TLS) | 2775 (unverschlüsselt); der TLS-Port wird Ihrem Konto zugewiesen |
Authentifizierung | Bearer-Token / API-Schlüssel | system_id + Passwort beim Bind |
Sitzungsmodell | Zustandsloses Request/Response | Langlebige gebundene Transceiver-Sitzung |
Durchsatzobergrenze | Keine festen Ratenlimits pro Konto; angepasst an Ihren Traffic | Keine festen Ratenlimits pro Konto; bis zu 30.000 SMS/Sekunde pro Knoten |
Idempotenz | Kein Idempotenz-Header: Die zurückgegebene Nachrichten-ID beibehalten und den Status vor dem erneuten Senden prüfen. | Keine im Protokoll: sequence_number ordnet nur eine Antwort ihrer Anfrage zu |
Zustellquittungs-Modell | Webhook-Callback | deliver_sm auf derselben Sitzung |
Kodierungskontrolle | Automatisch (GSM-7 / UCS-2) | Manueller data_coding-Parameter |
Behandlung verketteter SMS | Automatische Aufteilung | Manuelles UDH oder message_payload |
Behandlung eingehender MO | Webhook-Callback | Dieselbe Sitzung, deliver_sm |
Integrationsaufwand | Minuten (curl) bis Stunden | 1–2 Wochen (Bind-Logik, Retry, Sitzungs-Keepalive) |
Am besten für | Web-Apps, Prototypen, niedriges bis mittleres Volumen | Dauerhaftes hohes Volumen, Aggregatoren, Telekom |
Vierteljährlich geprüft · Korrekturen bitte an press@broadnet.me
bind_transceiverSitzung öffnen und authentifizierenbind_transceiver_respSitzung akzeptiertsubmit_smNachricht sendensubmit_sm_respAkzeptiert, Nachrichten-ID zurückgegebendeliver_smZustellungsbericht oder eingehende Nachrichtdeliver_sm_respBestätigtenquire_linkKeepalive im Leerlauf
Welche Seite zu welcher Arbeitslast passt.
Wann Sie eine REST-SMS-API wählen sollten
Wählen Sie REST, wenn die Last mittleres Volumen hat, das Team webnativ ist und der Integrationszeitplan kurz ist. REST ist 2026 die moderne Standardwahl für nahezu jeden CPaaS-Kunden.
- App-typische Volumina, bei denen der HTTPS-Overhead pro Anfrage nicht der Flaschenhals ist.
- Teams, deren Stack bereits HTTP-nativ ist (Web-Apps, Serverless, Mobile-Backends).
- Lasten, bei denen die Integrationsleichtigkeit die reine Durchsatzeffizienz übertrifft.
- Mehrkanalige Orchestrierung, bei der SMS neben WhatsApp, RCS und E-Mail steht.
Wann Sie SMPP wählen sollten
Wählen Sie SMPP, wenn dauerhafter Durchsatz, volle DLR-Kontrolle oder aggregatorartige Operationen im Spiel sind. SMPP ist älter und eigenartiger als REST, aber es ist das Protokoll, auf dem die Telekom-Welt tatsächlich läuft, und bei Skalierung ist die Effizienz real.
- Dauerhafte Versendungen von mehreren hundert Nachrichten pro Sekunde oder Lasten, die persistente Binds brauchen, wo REST die Kosten des Verbindungsaufbaus zu spüren beginnt.
- Lasten, die volle Kontrolle über data_coding, Gültigkeitsdauern und message_payload brauchen.
- Teams, die eingehende MO in hohem Volumen betreiben und deliver_sm auf derselben Sitzung brauchen.
- Aggregatoren, Telekom und alle, die Messaging als primäre Geschäftsfunktion betreiben.
Wo BroadNet steht.
Ehrliche Positionierung, kein Verkaufsgespräch. Manchmal ist die richtige Antwort, die andere Seite dieses Vergleichs zu nutzen — wir sagen es Ihnen.
Mit einem Telekom-Experten sprechenWir liefern beides und ermutigen Kunden, dort zu beginnen, wo ihr Team am produktivsten ist. Für die meisten webnativen Engineering-Teams bedeutet das REST. Unser Endpunkt POST /sms/sendSms, die OpenAPI-3.1-Spezifikation und das offizielle TypeScript SDK decken neunzig Prozent der Kundenbedürfnisse ab, ohne je SMPP zu berühren.
Wo SMPP zur richtigen Antwort wird, ist die Volumenschwelle — dauerhaft mehrere hundert Nachrichten pro Sekunde —, an der der HTTPS-Handshake pro Anfrage das Latenzbudget zu dominieren beginnt und das Verbindungs-Pooling zu einem lösenswerten Problem wird. An diesem Punkt bieten wir eine TLS-verschlüsselte SMPP 3.4 Transceiver-Bindung an, ohne feste Ratenlimits pro Konto, skaliert auf Ihren Traffic bis zu 30.000 SMS/Sekunde pro Knoten; Host, Port und Zugangsdaten werden Ihnen mit Ihrem Testzugang bereitgestellt.
Wir unterstützen auch SMPP 5.0 für Kunden, die die neuere message_payload-Semantik, Broadcast-Behandlung oder das sauberere Statusreporting brauchen. In der Praxis sind fünfundneunzig Prozent des weltweiten SMPP-Telekom-Traffics noch 3.4, und wir behandeln 3.4 als Standard.
Ein gängiges Muster: REST für den Anwendungscode, der einzelne OTPs und Benachrichtigungen sendet, SMPP für den hochvolumigen Kampagnen- und Massenversender. Beide binden an dasselbe SMSC, beide erzeugen dieselben Quittungen, beide werden gegen dieselbe Preisliste abgerechnet. Kunden können ohne Nachdenken mischen.
Die Fragen, die uns am häufigsten gestellt werden.
Was ist SMPP genau?
+
Was ist SMPP genau?
Short Message Peer-to-Peer Protocol — ein binäres TCP-Protokoll, das Ende der 1990er zur Zustellung von SMS zwischen SMSCs und ESMEs (external short message entities, also Anwendungen) entworfen wurde. Es ist das Protokoll, auf dem der Großteil des Telekomgrad-A2P-Traffics zwischen Aggregatoren und Betreibern tatsächlich läuft.
Ist SMPP schwieriger zu integrieren als REST?
+
Ist SMPP schwieriger zu integrieren als REST?
Deutlich schwieriger. Sie brauchen eine langlebige gebundene Sitzung, Keepalive-Logik (enquire_link), Sequenznummern-Verwaltung, Kodierungsbewusstsein und Bind-Zustandsbehandlung. Die meisten Teams nutzen eine bestehende SMPP-Bibliothek — Cloudhopper für Java, smpp.js für Node, jSMPP für Java-Unternehmen.
Warum nutzen hochvolumige Sender 2026 noch SMPP?
+
Warum nutzen hochvolumige Sender 2026 noch SMPP?
Durchsatzeffizienz. Eine einzelne gebundene SMPP-Sitzung kann 1.000+ Nachrichten pro Sekunde pro Transceiver schieben, während REST einen neuen TLS-Handshake pro Anfrage erfordert, sofern man Verbindungen nicht sorgfältig poolt. Für dauerhaft hohes Volumen ist das binäre Protokoll deutlich effizienter.
Stellt BroadNet SMPP oder REST zuerst bereit?
+
Stellt BroadNet SMPP oder REST zuerst bereit?
Beides, mit REST als Standard für Neuanmeldungen und SMPP als Vertriebsgespräch für Lasten, die dauerhaft mehrere hundert Nachrichten pro Sekunde senden oder persistente Binds brauchen. Dasselbe SMSC steht hinter beiden; dieselbe DLR-Semantik gilt.
Was ist mit SMPP 5.0?
+
Was ist mit SMPP 5.0?
Wir unterstützen es. In der Praxis nutzt die überwiegende Mehrheit des weltweiten A2P-SMPP-Traffics noch 3.4, und wir behandeln 3.4 als Standard für neue Anbindungen, sofern ein Kunde nicht ausdrücklich 5.0 verlangt.
Kann ich REST und SMPP vom selben Konto aus nutzen?
+
Kann ich REST und SMPP vom selben Konto aus nutzen?
Ja, gegen dasselbe SMSC. Die meisten Unternehmenskunden tun genau das — REST für den Anwendungscode und SMPP für den hochvolumigen Versender.
Wie werden Zustellquittungen unterschiedlich behandelt?
+
Wie werden Zustellquittungen unterschiedlich behandelt?
REST erhält einen Webhook-Callback an der von Ihnen registrierten URL. SMPP erhält deliver_sm-Frames auf derselben Sitzung, die die Nachricht übermittelt hat. Beide tragen dieselben DLR-Felder und dieselbe Quittungs-Nutzlast auf der BroadNet-Ebene.
Verliere ich an Zustellbarkeit, wenn ich REST anstelle von SMPP wähle?
+
Verliere ich an Zustellbarkeit, wenn ich REST anstelle von SMPP wähle?
Nein. Dieselbe Nachricht durchläuft an beiden Endpunkten dasselbe SMSC und dieselbe Betreiberroute – DLR-Genauigkeit und Routing sind identisch. Die Wahl ist rein betrieblicher Natur und hat nichts mit der Zustellbarkeit zu tun.
Weiterführende Lektüre.
Alle VergleicheWeitere Vergleiche.
Sprechen Sie mit einem Telekom-Experten.
Nennen Sie uns die Arbeitslast, die Märkte und die Volumina. Wir sagen Ihnen ehrlich, ob BroadNet die richtige Wahl ist, die falsche, oder Teil einer mehrschichtigen Architektur mit einer der Alternativen.