# SMS von Infobip migrieren

Diese Seite ordnet Infobips SMS-API, Blocklist und Zustellungsberichte den entsprechenden Funktionen von Bird zu. Folgen Sie dem [zentralen Migrationsleitfaden](/docs/guides/sms/migrate) 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`](/docs/api/reference/create-sms-message) 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.

```text
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](/products/sms/marketing/campaigns) 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](/docs/guides/sms/sending-sms#reserved-fields) 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](/docs/guides/sms/migrate#4-carry-over-your-opt-out-list). [Sperren lesen und verwalten](/docs/guides/sms/opt-outs-and-keywords#reading-and-managing-suppressions) 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](/docs/guides/sms/opt-outs-and-keywords#campaign-keywords). 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](https://www.standardwebhooks.com). [Einen Endpunkt erstellen](/docs/guides/webhooks#create-an-endpoint) 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](/docs/guides/sms/events#failure-events). Richten Sie Ihre Alarmierung auf diese Codes aus, statt auf Infobips numerische Gruppen- und Namenspaare.

## Umstellen

[Zielländer](/docs/guides/sms/migrate#1-enable-your-destination-countries), [Absender](/docs/guides/sms/migrate#2-set-up-a-sender) und die [schrittweise Traffic-Erhöhung](/docs/guides/sms/migrate#6-test-against-simulated-destinations) 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](/docs/guides/sms/10dlc): 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](/products/sms/compare/bird-vs-infobip): Produktevaluierung und Überlegungen zur Migration

- [SMS senden](/docs/guides/sms/sending-sms): die vollständige Nutzlast, auf die Sie umstellen
- [Abmeldungen und Schlüsselwörter](/docs/guides/sms/opt-outs-and-keywords): Schlüsselwortabdeckung pro Land und Verwaltung von Sperren
- [SMS-Ereignisse](/docs/guides/sms/events): das Ereignisvokabular für Ihren bisherigen Berichtshandler
- [Webhooks und Ereignisse](/docs/guides/webhooks): Endpunkteinrichtung und Prüfung nach Standard Webhooks

## Related resources

- [Choose a sender for your markets](/explained/sms/which-sms-sender-type-should-i-use) (answer)
- [Check your message segments](/tools/sms-segment-calculator) (tool)
- [Compare SMS providers](/products/sms/compare) (product)