Messaging-API auswählen: die Checkliste für CTOs

Diese Checkliste richtet sich an CTOs, Engineering-Leads und Architekten, die eine Messaging-API für SMS, WhatsApp, RCS und weitere Kanäle auswählen. Sie macht aus einem vagen Anbietervergleich konkrete Fragen, Tests, die Sie an einem Nachmittag durchführen können, und eine Bewertungstabelle, die Sie gegenüber Finanz- und Sicherheitsteams vertreten können.

Haben Sie bereits einen Anbieter gewählt und müssen nun die Integration bauen, lesen Sie stattdessen unseren Leitfaden zur Integration einer Messaging-API. In diesem Artikel geht es um die Entscheidung davor.

Was sollte ein CTO an einer Messaging-API bewerten?

Bewerten Sie, was die Ergebnisse im Produktivbetrieb beeinflusst: ob Nachrichten ankommen, ob Sie sehen, was passiert ist, ob die Integration Ausfälle übersteht und ob sie compliant bleibt. Funktionslisten ähneln sich zwischen Anbietern; diese Eigenschaften nicht.

Deckt die API die benötigten Kanäle ab?

Achten Sie auf eine Basis-URL, ein Authentifizierungsschema und ein Modell für Zustellstatus über alle Kanäle. Getrennte Integrationen je Kanal vervielfachen den zu pflegenden Code und die Stellen, an denen ein Status verloren gehen kann.

• Listen Sie Ihre Kanäle für die nächsten zwei Jahre auf, nicht nur für heute. Teams, die mit SMS-OTP beginnen, ergänzen oft WhatsApp-Vorlagen, dann RCS, dann E-Mail oder Push.
• Prüfen Sie die Kanaltiefe, nicht nur das Logo. Können Sie bei WhatsApp über die API Vorlagen verwalten, interaktive Nachrichten senden und die Freigabe verfolgen? Sind bei SMS Zwei-Wege-Kommunikation, Unicode und Nummernabfrage verfügbar?
• Prüfen Sie den Fallback. Kann die Plattform auf RCS oder SMS ausweichen, wenn eine WhatsApp-Nachricht nicht zugestellt wird, und lässt sich die Reihenfolge je Anwendungsfall konfigurieren? Unser Vergleich WhatsApp vs. SMS vs. RCS erklärt, wann welcher Kanal passt.

Wie beurteilen Sie die Routenqualität?

Fragen Sie, wie der Anbieter jeden Netzbetreiber in Ihren wichtigsten Märkten erreicht, und prüfen Sie das dann selbst. Die Routenqualität bestimmt, ob die Nachricht ankommt, ob Ihre Absenderkennung erhalten bleibt und ob der Zustellbericht widerspiegelt, was tatsächlich passiert ist.

Eine direkte Route bedeutet, dass der Anbieter mit dem Netzbetreiber oder einem autorisierten Partner verbunden ist, auf Basis einer Vereinbarung, die Application-to-Person-Traffic (A2P) abdeckt. Eine Grey Route leitet A2P-Traffic über Wege, die dafür nicht vorgesehen sind, etwa über Verbraucher-SIM-Verbindungen. Grey Routes mögen auf einer Preisliste günstiger aussehen, bergen aber echte Risiken:

• Die Absenderkennung wird durch eine zufällige Nummer ersetzt, was Vertrauen und die gewohnte OTP-Autovervollständigung zerstört;
• Netzbetreiber erkennen und blockieren den Traffic, mitunter mitten in einer Kampagne;
• Zustellberichte können von der Route statt vom Netz erzeugt werden, sodass „zugestellt“ nicht unbedingt zugestellt bedeutet.

Fragen, die Sie stellen sollten:

1. Welche unserer Zielländer und Netzbetreiber erreichen Sie direkt?
2. Wie handhaben Sie die Registrierung von Absenderkennungen in jedem Land?
3. Woher stammen Ihre Zustellberichte, und geben Sie den Fehlercode des Netzbetreibers weiter?
4. Was passiert mit unserem Traffic, wenn sich eine Route verschlechtert? Erfolgt das Umrouten automatisch, und informieren Sie uns?

Testen Sie dann: Senden Sie an echte Endgeräte bei jedem großen Netzbetreiber, prüfen Sie die angezeigte Absenderkennung und vergleichen Sie die Bestätigungen mit dem, was die Telefone anzeigen. Hintergründe dazu, wie Business-SMS die Netzbetreiber erreicht, finden Sie unter Was ist A2P-SMS?.

Wie werden Zustellberichte und Webhooks gehandhabt?

Der Anbieter sollte Zustellstatus an Ihren HTTPS-Endpunkt senden, in einem einheitlichen Format über alle Kanäle, und Ihnen eine Möglichkeit bieten, verpasste Ereignisse nachzuholen. Jede Nachricht einzeln abzufragen, ist kein tragfähiges Design.

So sieht es gut aus:

• Eine dokumentierte Statusliste. Zum Beispiel SUBMITTED, SENT, DELIVERED, READ, FAILED und REJECTED, mit Angabe, welche endgültig sind. Unser Leitfaden zum Zustellstatus erklärt, was jeder Status in der Praxis bedeutet.
• Fehlergründe. Ein FAILED- oder REJECTED-Status sollte den Grund des Netzbetreibers oder Kanals enthalten, sofern einer vorliegt.
• Wiederherstellung. Können Sie bei einem Ausfall Ihres Endpunkts die erneute Zustellung von Bestätigungen für einen Zeitraum anfordern oder den Status pro Empfänger abrufen?
• Ehrliche Hinweise zu Reihenfolge und Duplikaten. Ereignisse können in falscher Reihenfolge und mehrfach eintreffen. Eine Dokumentation, die das sagt, ist vertrauenswürdiger als eine, die es verschweigt.
• Absicherung des Endpunkts. Fragen Sie, ob Webhooks signiert sind. Falls nicht, sollte der Anbieter erklären, wie der Endpunkt zu schützen ist, etwa nur HTTPS, ein nicht erratbarer Pfad, strenge Validierung des Inhalts und Prüfung des Zustands vor unumkehrbaren Aktionen.

Welche Authentifizierung und Sicherheit sollten Sie erwarten?

Mindestens: Tokens in einem Authorization-Header über TLS, niemals in URLs; ein klarer Prozess zum Rotieren und Widerrufen von Zugangsdaten; und unabhängig geprüfte Sicherheitskontrollen. Bearer-Tokens sind in RFC 6750 definiert, und die OWASP API Security Top 10 eignen sich gut, um sie mit dem Anbieter durchzugehen.

Fragen Sie:

• Wie werden Tokens ausgegeben, eingeschränkt und widerrufen? Können Sie getrennte Tokens je Dienst oder Umgebung haben? Wie schnell wird ein kompromittiertes Token widerrufen?
• Werden Zugangsdaten jemals als URL-Parameter übergeben? Manche älteren HTTP-APIs erwarten Benutzername und Passwort noch im Query-String, wo sie in Logs landen. Vermeiden Sie das bei neuen Integrationen.
• Gibt es IP-Allowlisting, und wo? Bei SMPP-Binds ist es üblich; prüfen Sie, ob es auch für REST gilt.
• Welche Zertifizierungen decken den Dienst ab? Fordern Sie das Zertifikat oder den Bericht an, nicht nur ein Logo, und prüfen Sie den Geltungsbereich.
• Wo und wie lange werden Nachrichteninhalte gespeichert? Das ist für Datenschutzprüfungen relevant.

Mit welchen Rate Limits und welchem Durchsatz sollten Sie planen?

Erwarten Sie dokumentierte Standardlimits, eine Antwort 429 Too Many Requests (RFC 6585) mit einem Retry-After-Header bei Überschreitung und einen Prozess, um höhere Obergrenzen für Produktionsspitzen zu vereinbaren. Undokumentierte Limits entdecken Sie sonst während Ihrer größten Kampagne.

• Fragen Sie nach Limits je Schnittstelle: REST-Anfragen, SMPP-Binds und Lookup-Aufrufe haben oft getrennte Limits.
• Prüfen Sie Bulk-Endpunkte. Eine Anfrage mit einer Empfängerdatei schont die Limits mehr als Tausende Einzelanfragen.
• Fragen Sie, wie Spitzen gehandhabt werden. Flash Sales und Störungsmeldungen erfordern Planung mit dem Anbieter, nicht Hoffnung.
• Planen Sie Ihre Seite. Eine Warteschlange und ein Token-Bucket-Limiter vor der API halten mehrere Worker innerhalb Ihres Kontingents.

Unsere Referenz zu Fehlern und Limits zeigt, wie eine solche Dokumentation in der Praxis aussieht.

Wie gut sind SDKs und Dokumentation?

Eine gute Dokumentation ermöglicht es einem Entwickler, eine echte Nachricht zu senden, einen Status zu empfangen und einen Fehler zu behandeln, ohne ein Support-Ticket zu eröffnen. Fordern Sie das OpenAPI-Dokument an; ein Anbieter, der eines pflegt, kann Ihnen generierte Clients, Postman-Collections und exakte Feldnamen liefern.

Qualitätsmerkmale:

• eine OpenAPI-3.x-Spezifikation, die der Live-API entspricht;
• mindestens ein gepflegtes SDK sowie einfache HTTP-Beispiele für andere Sprachen;
• exakte Feldnamen der Anfragen, ein dokumentiertes Fehlerformat mit maschinenlesbarem Code und Beispielantworten;
• ein Quickstart, der mit einem Zustellstatus endet, nicht nur mit „200 OK“;
• ehrliche Hinweise darauf, was nicht unterstützt wird.

Wie geht die API mit Wiederholungen und Duplikaten um?

Eine Sendeanfrage kann auf dem Server erfolgreich sein, während die Antwort verloren geht; eine blinde Wiederholung schickt dem Kunden dann dieselbe Nachricht zweimal. Fragen Sie, wie der Anbieter das verhindern lassen will.

Manche APIs akzeptieren einen Idempotency Key: Sie senden einen eindeutigen Wert mit der Anfrage, und eine Wiederholung mit demselben Wert liefert das ursprüngliche Ergebnis. Andere, darunter unsere, akzeptieren keinen; das dokumentierte Muster lautet dann, jede Sendung vor dem Absenden in Ihrer Datenbank zu protokollieren, die zurückgegebene Nachrichten-ID zu speichern und nach einem Timeout vor einer erneuten Sendung nach Belegen für die Annahme zu suchen. Beide Ansätze funktionieren, wenn sie dokumentiert sind. Was nicht funktioniert, ist ein Anbieter, der sich darüber keine Gedanken gemacht hat. Die Seite zu Fehlern und Limits zeigt das Muster „erst protokollieren, dann senden“.

Gibt es einen sicheren Testzugang?

Sie sollten mit echten Nachrichten an Nummern testen können, die Sie kontrollieren, bevor Traffic Kunden erreicht. Fragen Sie, wie der Testzugang aussieht: eine Sandbox, die Antworten simuliert, oder echte Sendungen, beschränkt auf verifizierte Nummern.

Simulierte Sandboxes sind für Unit-Tests nützlich, bilden das Verhalten der Netzbetreiber aber selten ab. Echte Sendungen an verifizierte Nummern zeigen Ihnen die tatsächliche Anzeige der Absenderkennung, die Kodierung und die Bestätigungen. Fragen Sie, wie lange der Wechsel vom Test- zum Produktivzugang dauert, denn die Freigabe von Absenderkennungen folgt in manchen Ländern dem Zeitplan der Regulierungsbehörde.

Brauchen Sie eine SMPP-Option?

Am ersten Tag wahrscheinlich nicht, später vielleicht schon. SMPP v3.4 ist das Telekommunikationsprotokoll für den SMS-Austausch über eine dauerhafte Verbindung und eignet sich für hohe, gleichmäßige SMS-Volumen, Aggregatoren und Reseller. Fragen Sie, ob der Anbieter SMPP über TLS anbietet, wie Binds bereitgestellt werden und ob dieselben Routen wie für REST genutzt werden. Unser Leitfaden SMS-API vs. SMPP vergleicht beides im Detail.

Können KI-Agenten die API sicher nutzen?

Wenn Ihre Teams KI-Assistenten nutzen oder Agenten bauen, lässt ein Model-Context-Protocol-Server (MCP) sie Messaging-Tools ohne eigenen Glue-Code finden und aufrufen. Fragen Sie, was der Agent tun kann und mit welchen Berechtigungen.

Fragen, die Sie stellen sollten:

• Handelt der MCP-Server mit demselben Token und denselben Berechtigungen wie unser eigener Code?
• Können wir nur die Tools aktivieren, die ein Agent braucht, etwa Zustellberichte ohne Sende-Tools?
• Gibt es temporäre Schlüssel für Experimente?
• Erscheinen Sendungen in denselben Zustellberichten, damit wir das Verhalten von Agenten prüfen können?

Unsere Dokumentation zum MCP-Server zeigt ein Beispiel für solche Kontrollen.

Welche Compliance-Unterstützung sollte der Anbieter bieten?

Der Anbieter sollte Ihnen helfen, Absenderkennungen zu registrieren, wo das erforderlich ist, die Verarbeitung von Abmeldungen unterstützen und Daten unter anerkannten Sicherheits- und Datenschutzkontrollen verarbeiten. Für die Einwilligung bleiben Sie verantwortlich; der Anbieter sollte sie praktikabel machen.

• Absenderkennungen: Manche Länder verlangen die Registrierung alphanumerischer Absenderkennungen, manche regulatorische Kennungen in jeder Nachricht. Siehe unseren Leitfaden zur Registrierung von Absenderkennungen in den VAE und Saudi-Arabien.
• Einwilligung: Fragen Sie, wie Abmeldungen bei Zwei-Wege-SMS erfasst werden und wie sie Ihre Systeme erreichen. Unser Leitfaden zur Einwilligung behandelt die Pflichten.
• Datenschutz: Fragen Sie nach Auftragsverarbeitungsverträgen, Hosting-Standort, Speicherdauer und Unterauftragsverarbeitern.

Was sollten Sie zu Support und SLAs fragen?

Betrachten Sie die Supportbedingungen als Teil des Produkts und lassen Sie sie sich schriftlich geben. Vergleichen Sie keine Schlagzahlen aus Vertriebsunterlagen, sondern das, wozu sich der Vertrag verpflichtet.

• Wie werden Störungen erkannt, kommuniziert und abgeschlossen?
• Welche Zeiten, Zeitzonen und Sprachen deckt der Support ab?
• Wer bearbeitet Probleme auf Netzbetreiberseite, etwa eine in einem Land gesperrte Absenderkennung?
• Gibt es während der Integration einen festen Ansprechpartner oder Onboarding-Engineer?
• Wozu verpflichtet sich die Vereinbarung, wie wird das gemessen und was passiert, wenn die Zusage verfehlt wird?

Wie transparent sind die Preise?

Sie sollten eine Monatsrechnung aus einer veröffentlichten Preisliste und Ihren Volumen abschätzen können. Fragen Sie:

• Gelten die Preise pro Nachricht, pro Segment oder pro zugestellter Nachricht, und unterscheidet sich das je Kanal?
• Welche Drittentgelte werden separat weitergegeben, etwa Metas WhatsApp-Entgelte?
• Erfolgt die Abrechnung per Prepaid oder Postpaid, und was passiert, wenn das Guthaben mitten in einer Kampagne aufgebraucht ist?
• Werden Nummernabfrage, Registrierung von Absenderkennungen und dedizierte SMPP-Binds separat berechnet?

Denken Sie daran, dass Unicode und lange Nachrichten mehr SMS-Segmente verbrauchen. Unser Leitfaden zu Zeichenlimits erklärt, warum eine arabische Kampagne mehr kosten kann als ihre englische Version.

Wie bewerten Sie Anbieter?

Führen Sie mit jedem Anbieter der Shortlist denselben praktischen Test durch und bewerten Sie alle in einer Tabelle. Gewichten Sie die Kriterien nach Ihren eigenen Prioritäten; die folgenden Gewichte sind ein Ausgangspunkt, kein Standard.

Vorgehen bei der Bewertung

1. Erstellen Sie eine Shortlist mit zwei bis vier Anbietern, die Ihre Kanäle und Länder abdecken.
2. Beantragen Sie bei jedem einen Testzugang und notieren Sie, wie lange das dauert.
3. Führen Sie mit jedem Anbieter den unten beschriebenen Smoke-Test durch.
4. Senden Sie an echte Endgeräte bei jedem großen Netzbetreiber in Ihren wichtigsten Märkten.
5. Stellen Sie die schriftlichen Fragen aus jedem Abschnitt oben.
6. Bewerten Sie jedes Kriterium von 1 bis 5, multiplizieren Sie mit dem Gewicht und addieren Sie.
7. Besprechen Sie die beiden besten Ergebnisse mit Sicherheit, Finanzen und dem Team, das die Integration betreiben wird.

Ein kurzer Smoke-Test

Die Dokumentation jedes Anbieters sollte Ihnen etwas in dieser Art ermöglichen. Hier der entsprechende Aufruf unserer API, wie im Quickstart gezeigt:

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

Ein erfolgreicher Aufruf liefert 200 OK mit der Nachrichten-ID als reinem Text. Prüfen Sie während des Tests vier weitere Punkte: was bei einem absichtlich ungültigen Token passiert (erwartet: 401), bei einer fehlerhaften Nummer (erwartet: 400 mit Fehlercode), bei einer arabischen Nachricht (sie muss als Unicode gesendet werden; siehe die SMS-API-Referenz) und ob ein DELIVERED-Status Ihren Webhook erreicht.

Praxisbeispiel: ein Fintech wählt einen Anbieter für OTP und Benachrichtigungen

„Nakheel Pay“ (fiktiv), eine Payment-App in Saudi-Arabien und den VAE, braucht jetzt SMS-OTP und innerhalb eines Jahres WhatsApp-Transaktionsbenachrichtigungen.

• Shortlist: drei Anbieter, die beide Länder und beide Kanäle abdecken.
• Smoke-Test: Der Testzugang des einen Anbieters kommt innerhalb weniger Tage; ein anderer verlangt vor jedem Test einen langen Vertriebsprozess. Das wird unter Testzugang festgehalten.
• Tests auf Endgeräten: Bei einem Anbieter erscheint die registrierte Absenderkennung bei jedem getesteten Netzbetreiber; bei einem anderen zeigt ein Netzbetreiber einen numerischen Absender. Dieser Anbieter wird zu seiner Route befragt und erhält bei der Routenqualität eine niedrige Bewertung.
• Duplikate: Das Team klärt, wie jeder Anbieter mit Wiederholungen umgeht. Einer akzeptiert einen Idempotency Key, ein anderer dokumentiert das Muster „erst protokollieren, dann senden“. Beides ist akzeptabel; das Team baut das Muster einmalig in seinen Sendedienst ein.
• Sicherheitsprüfung: Das Sicherheitsteam prüft den Geltungsbereich der Zertifikate und den Prozess zum Widerruf von Tokens.
• Entscheidung: Die gewichtete Tabelle spricht für den Anbieter mit direkten Routen, normalisierten Webhooks und einer SMPP-Option für späteres Wachstum, obwohl ein anderer einen etwas niedrigeren SMS-Listenpreis hatte.

Häufige Fehler bei der Auswahl einer Messaging-API

• Allein nach dem Preis pro Nachricht entscheiden. Nicht zugestellte Nachrichten und ersetzte Absenderkennungen kosten mehr, als sie einsparen.
• Nur in einer simulierten Sandbox testen. Das Verhalten der Netzbetreiber zeigt sich nur auf echten Endgeräten.
• Duplikate ignorieren. Eine Wiederholungsschleife ohne Schutz versendet OTPs doppelt.
• „Gesendet“ mit „zugestellt“ gleichsetzen. Fragen Sie, wie endgültige Status gemeldet werden.
• Die Sicherheitsprüfung aufschieben, bis nach der Integration, wenn ein Anbieterwechsel teuer ist.
• Mündliche Zusagen akzeptieren. Support- und Servicebedingungen gehören in den Vertrag.
• Grenzen dieser Checkliste: Sie beschreibt gute Praxis und ist keine Rechtsberatung. Klären Sie die Regeln je Land mit den Regulierungsbehörden und Ihrem Anbieter.

So unterstützt OmniChannels.ai

OmniChannels.ai bietet Ihnen eine REST-API unter https://api.broadnet.me für SMS, WhatsApp, RCS, Messenger, Instagram, Telegram, E-Mail und Push, mit Bearer-Token-Authentifizierung, rund 330 dokumentierten Pfaden, einer OpenAPI-3.1-Spezifikation und dem TypeScript-SDK @broadnet/cpaas-sdk. Zustellstatus kommen in einem einheitlichen Format an Ihrem Webhook an. Für hohe SMS-Volumen steht SMPP 3.4 über TLS zur Verfügung, und ein MCP-Server lässt KI-Agenten dieselbe API nutzen. Der Traffic läuft über BroadNets direkte Verbindungen zu mehr als 1.000 Netzbetreibern und Aggregatoren. Der Testzugang ist auf Ihre eigenen verifizierten Nummern beschränkt; starten Sie mit der Entwicklerübersicht.