SMS von Infobip migrieren

Diese Seite ordnet Infobips SMS-API, Blocklist und Zustellungsberichte den entsprechenden Funktionen von Bird zu. Folgen Sie dem zentralen Migrationsleitfaden der Reihe nach und verwenden Sie diese Zuordnungen für die Schritte 3, 4 und 5.

Zwei Unterschiede bestimmen den Großteil der Umstellung. Infobips Nutzlast ist für den Massenversand aufgebaut. Eine Nachricht an eine Person steht deshalb in einem Nachrichten-Array, dessen Einträge jeweils ein Empfänger-Array enthalten. Der Text liegt zwei Ebenen tiefer in content.text. POST /v1/sms/messages erwartet from, to und text auf der obersten Ebene. Außerdem erhält jedes Infobip-Konto eine eigene Basis-URL im Format xxxxx.api.infobip.com mit Authentifizierung über Authorization: App <key>. Bird sendet über einen regionalen Host mit einem Bearer-Schlüssel. Der in Ihrem Code hinterlegte Host ändert sich daher zusammen mit der Nutzlaststruktur.

Übergeben Sie dies Ihrem Agenten

Verwenden Sie diese Anweisung in Ihrem Coding-Agenten. Sie beginnt mit einer Bestandsaufnahme und erstellt vor jeder Produktionsänderung einen überprüfbaren Migrationsplan.

Codebeispiel

Help me migrate my SMS integration from Infobip to Bird.
1. Inspect this repository's sends, senders, callbacks, schedules, templates, opt-outs and tests. List the traffic and behavior that must survive the migration.
2. Read the Markdown guides at https://bird.com/docs/guides/sms/migrate/infobip.md and https://bird.com/docs/guides/sms/migrate.md. Use an existing authenticated Bird MCP or CLI connection. If neither is available, follow https://bird.com/docs/ai/set-up-your-agent.md. Discover the actual operations; do not invent commands or ask me to paste credentials into chat.
3. Prepare the code changes, sender/destination requirements, consent migration, webhook verification and rollout/rollback plan. Preserve the scope of each customer's preferences, including requests outside SMS replies. Separate API batches from audience broadcasts and preserve any behavior that has no direct endpoint equivalent.
4. Show me the exact affected resources, destinations, test volume and known costs before an action that sends messages, spends money, registers or changes a sender, or moves production traffic. Require explicit human authorization for each paid submission or production change. Name one-off 10DLC registration and resubmission fees before requesting approval. An existing explicit approval for that exact action is sufficient; broad migration approval is not. Simulated SMS destinations are billable and still require authorization.
5. If I am keeping Infobip numbers, prepare the human support port request and obtain authorization to send it. Read bird support-tickets create --help, then use the available CLI or MCP support operation with the reviewed number list and requirements. Return the ticket ID and follow the reply; support arranges the port on its own schedule, separately from the code cutover.
6. Run local and intercepted tests first. When authorized, perform the agreed bounded integration tests, inspect accepted and final outcomes separately, and report failures or uncertainty. Do not claim a delivery receipt proves reading or that request idempotency guarantees exactly-once delivery.
7. Keep production cutover and retiring the old provider as explicit steps in the approved rollout. Finish with the diff, evidence, unresolved requirements and the next action.

Den Sendeaufruf zuordnen

Die Umbenennungstabelle ist kurz, weil die eigentliche Arbeit in der Strukturänderung liegt:

Funktion	Infobip	Bird
Empfänger	messages[].destinations[].to	to (einer pro Anfrage)
Absender	messages[].sender	from
Nachrichtentext	messages[].content.text	text
Zweck	(keine Angabe)	category, bei Freitext erforderlich
Zustellungsberichte	webhooks.delivery, pro Nachricht	ein Workspace-Webhook, der die unten aufgeführten Zustellungsereignisse abonniert
Zurückgegebener Kontext	webhooks.callbackData	metadata; beachten Sie den Größenhinweis unten
Kampagnengruppierung	options.campaignReferenceId	tags, ausschließlich zum Filtern; siehe unten
Flash	options.flash	keine Entsprechung
Gültigkeit	options.validityPeriod	keine Entsprechung: validity_period wird abgelehnt
Zustellungsfenster	options.deliveryTimeWindow	keine Entsprechung
Sichere Wiederholungen	(keine Angabe in den generierten Clients)	Header Idempotency-Key

Hinweise zur Umstellung:

Drei Ebenen entfallen. Die Verschachtelung ermöglicht viele Nachrichten und Empfänger in einer Anfrage. Für eine Nachricht an eine Person erwartet Bird die drei Felder auf der obersten Ebene. Den Builder, der die Arrays zusammensetzt, entfernen Sie daher bei der Umstellung.
callbackData ist größer als metadata. Infobip akzeptiert bis zu 4.000 Zeichen und gibt sie im Zustellungsbericht zurück. metadata bei Bird ist auf 2 KB in serialisierter Form begrenzt und wird bei jedem Ereignis zur Nachricht zurückgegeben, auch vor dem abschließenden Ereignis. Die Rückgabe erfolgt also häufiger, die Größenbegrenzung ist jedoch enger. Inhalte nahe an der Grenze müssen Sie auf einen nachschlagbaren Schlüssel kürzen, statt sie vollständig mitzuführen.
campaignReferenceId ist Berichtskontext und migriert keine Kampagne. Die tags von Bird sind {name, value}-Paare, die als Abfragedimensionen dienen. So können Sie Analysen wie bisher nach Kampagnen aufteilen. Ein Kampagnenobjekt entsteht dadurch nicht: Ein Tag erstellt oder konfiguriert keinen Broadcast. Prüfen Sie bei der Migration von Zielgruppenkampagnen den Kampagnenworkflow separat.
campaignReferenceId ist kein Idempotenzschlüssel. Infobip definiert das Feld als ID zur Verfolgung der Kampagnenleistung. Es gruppiert Nachrichten, verhindert aber keine Duplikate. Wer sich für sichere Wiederholungen darauf verlassen hat, war nicht geschützt. Hier übernimmt das der Header Idempotency-Key.
Für category gibt es keine Entsprechung. Infobips Nachrichtenoptionen betreffen Gültigkeit, Zustellungsfenster, Flash und regionale Einstellungen. Keine davon erklärt, warum die Nachricht gesendet wird. Entscheiden Sie für jeden Nachrichtentyp, ob er transactional, marketing, authentication oder service ist.
Zwei Optionsfelder haben keine Entsprechung. validityPeriod ist reserviert und liefert 422 SMSUnsupportedFeature. Für deliveryTimeWindow gibt es kein Gegenstück; Zeitfenster für den Versand verwalten Sie daher in Ihrem eigenen Dispatcher.

Abmeldungen übernehmen

Infobip führt eine Blocklist mit Empfängern, die sich von Ihrer Kommunikation abgemeldet haben. Sie verwalten diese über die Blocklist-API oder über People in der Weboberfläche. Sendungen an eingetragene Empfänger werden abgelehnt. Schlüsselwort-Trigger fügen Einträge automatisch hinzu: Sendet ein Abonnent STOP, erscheint er ohne Zutun Ihrer Anwendung auf der Liste.

Damit ist der Export unter den hier verglichenen Anbietern am einfachsten und die Vervielfachung am größten. Ein Blocklist-Eintrag gilt für einen Abonnenten im gesamten Konto; eine Sperre bei Bird gilt für ein Absender-Abonnenten-Paar. Aus jedem Eintrag werden daher so viele Sperren, wie Sie Absender haben. Eine Blocklist mit tausend Einträgen und sechs Absendern ergibt sechstausend Datensätze. Berechnen Sie diesen Faktor vor Beginn: Er entscheidet, ob ein Import eine Minute dauert oder Batches und ein Fortschrittsprotokoll benötigt.

Bewahren Sie den ursprünglichen Geltungsbereich der Blocklist. Verengen Sie eine Abmeldung bei der Migration nicht, nur weil das neue technische Modell engere Paare darstellen kann. Eine Workspace-weite Präferenz kann einen umfassenderen Wunsch abbilden. Sie wird getrennt von Absendersperren verwaltet. Prüfen Sie beide bei der Entscheidung über die Sendeberechtigung.

Importieren Sie die Einträge über die Sperrschleife. Sperren lesen und verwalten beschreibt den Befehl und erklärt, warum eine manuelle Sperre jede Kategorie einschließlich transaktionaler Nachrichten blockiert.

Nach der Umstellung beantwortet Bird Abmeldeschlüsselwörter anhand seines eigenen Länderkatalogs. Ihre bisherigen Schlüsselwort-Trigger müssen Sie daher nicht nachbauen. Eigene Schlüsselwörter werden zu Schlüsselwortregeln. Gründe werden getrennt gespeichert. Wenn ein als manual importiertes Paar später STOP sendet, bestehen zwei Datensätze. Der Versand bleibt gesperrt, bis beide beendet sind.

Zustellungsstatus zuordnen

Vergleichen Sie mit dieser Tabelle die Lebenszykluskonzepte, statt Ereignisse mechanisch umzubenennen. Bird wählt ein Fehlerereignis anhand des gemeldeten Status und Grunds. Eine abgelehnte API-Anfrage erstellt keine Nachricht. Eine Ablehnung nach der Annahme kann sms.rejected auslösen, auch bei einer Ablehnung durch den Netzbetreiber. Fehlende Zustellungsnachweise bleiben unbekannt. Bewahren Sie den ursprünglichen Anbieterstatus und Code zusammen mit Ihrem normalisierten Ergebnis auf.

Infobip meldet in jedem Zustellungsbericht eine Statusgruppe und einen Statusnamen. Bird gibt einen Ereignistyp aus:

Ergebnis	Infobip-Statusgruppe	Bird
Die API hat die Nachricht angenommen	PENDING	sms.accepted
An den Netzbetreiber übergeben	PENDING	sms.sent
Netzbetreiber hat die Zustellung bestätigt	DELIVERED	sms.delivered
Netzbetreiber hat Nichtzustellung gemeldet	UNDELIVERABLE	sms.undelivered
Dauerhafter Fehler	REJECTED	sms.failed
Vor dem Versand abgelehnt	REJECTED	sms.rejected
Gültigkeitsfenster abgelaufen	EXPIRED	sms.expired

EXPIRED verdient besondere Beachtung: Bei Infobip deckt dieser Status zwei verschiedene Fälle ab, von denen hier nur einer existiert. Infobip lässt eine Nachricht ablaufen, wenn die Gültigkeitsdauer seiner eigenen Plattform endet, standardmäßig nach 48 Stunden, oder wenn der Netzbetreiber abgelaufen als endgültigen Status meldet. Bird legt kein eigenes Gültigkeitsfenster fest und betreibt keinen Timer zum Beenden einer Nachricht. sms.expired stammt daher ausschließlich aus dem Zustellungsbericht des Netzbetreibers. Der vom Netzbetreiber gemeldete Fall lässt sich zuordnen. Für den Plattform-Timer gibt es kein Gegenstück. Eine Nachricht, deren Zeit bei Infobip abgelaufen wäre, bleibt hier unterwegs, bis der Netzbetreiber entscheidet.

REJECTED erscheint absichtlich zweimal. Infobip verwendet es sowohl für eine selbst abgelehnte Nachricht als auch für eine vom Netzbetreiber zurückgewiesene Nachricht. Bird wählt seine Ereignisse anhand des Verarbeitungs- oder Netzbetreiberergebnisses und des jeweiligen Grunds. Eine Ablehnung durch den Netzbetreiber kann sms.rejected auslösen. Der Statusname innerhalb der Gruppe unterscheidet die Fälle. Ein Handler, der bisher nur die Gruppe geprüft hat, benötigt nach der Umstellung auch den Namen. PENDING umfasst ebenfalls zwei Zeilen: In dieser Gruppe bleibt die Nachricht von der Annahme bis zum Eingang eines abschließenden Berichts.

Mit den Namen ändern sich drei Abläufe:

Abonnements ersetzen Webhooks pro Nachricht. Bei Infobip benennt jede Nachricht einen Webhook. Ziel und Inhaltstyp legt somit der jeweilige Aufrufer fest. Bird liefert JSON an Endpunkte, die Ihr Workspace registriert. Jeder abonniert die gewünschten Ereignistypen. Ein zweiter Empfänger benötigt dadurch ein zweites Abonnement und keine Änderung jeder Aufrufstelle.
Die Auswahl pro Nachricht entfällt, einschließlich XML. Bei Infobip kann eine Nachricht JSON oder XML wählen und bis zu 4.000 Zeichen Callback-Daten mitführen. Bird sendet ausschließlich JSON. Aus callbackData wird metadata, das bei jedem Ereignis dieser Nachricht zurückgegeben wird, nicht ausschließlich im Bericht.
Aus Abrufen wird Zustellen. Infobip bietet neben dem Empfang auch das Abrufen von Berichten über einen Berichts-Endpunkt. Bird hat kein entsprechendes Polling für Ereignisse. Abonnieren Sie die Ereignisse und lesen Sie den Nachrichtenstatus bei Bedarf über die API.

Registrieren Sie den Endpunkt einmal mit den Ereignistypen, die Ihr Handler benötigt. Die oben aufgeführten sms.*-Ereignisse bilden die Abonnementliste; einen Platzhalter für alle gibt es nicht. Bird sendet JSON mit einer Signatur nach Standard Webhooks. Einen Endpunkt erstellen enthält den Befehl und den entscheidenden Schritt beim ersten Aufruf: Speichern Sie das Signaturgeheimnis, das die Antwort genau einmal anzeigt.

Bird meldet einen Fehler mit einem standardisierten error-Code wie invalid_destination, content_rejected, provider_unavailable oder recipient_opted_out. Die vollständige Liste steht auf der Ereignisseite. Richten Sie Ihre Alarmierung auf diese Codes aus, statt auf Infobips numerische Gruppen- und Namenspaare.

Umstellen

Zielländer, Absender und die schrittweise Traffic-Erhöhung sind anbieterunabhängig und im zentralen Leitfaden beschrieben. Drei Infobip-spezifische Punkte gehören in den Umstellungsplan.

Der Host ändert sich in der Konfiguration. Ihre Infobip-Basis-URL wird pro Konto vergeben. Bird sendet über einen regionalen Host, der beim Erstellen Ihres Workspace ausgewählt wurde. Ermitteln Sie vor der Umstellung jede Stelle, an der der Host hinterlegt ist, einschließlich Umgebungsvariablen, Secret-Managern und Deployment-Manifesten. Eine übersehene Stelle führt erst zur Laufzeit zu einem Fehler, nicht beim Build.

Ihre 10DLC-Marke und Kampagne sind über Infobips API zur Rufnummernregistrierung bei The Campaign Registry registriert. Sie werden nicht automatisch zu Registrierungen bei Bird. Bestätigen Sie das anwendbare Migrations- oder Registrierungsverfahren, bevor Sie kostenpflichtige Vorgänge einreichen. Beginnen Sie mit Für 10DLC registrieren: Der Leitfaden erläutert jedes Feld, die vom Register anerkannten Unternehmenstypen und den Anforderungsaufruf. Dieser zeigt, welche Angaben vor dem Erstellen der Marke nötig sind. Das Erstellen ist der kostenpflichtige Schritt.

Ihre Rufnummern bei Infobip benötigen eine Portierung, die der Support nach seinem eigenen Zeitplan organisiert.

Nächste Schritte

Bird und Infobip für SMS vergleichen: Produktevaluierung und Überlegungen zur Migration
SMS senden: die vollständige Nutzlast, auf die Sie umstellen
Abmeldungen und Schlüsselwörter: Schlüsselwortabdeckung pro Land und Verwaltung von Sperren
SMS-Ereignisse: das Ereignisvokabular für Ihren bisherigen Berichtshandler
Webhooks und Ereignisse: Endpunkteinrichtung und Prüfung nach Standard Webhooks