# SMS von Bandwidth migrieren

Diese Seite ordnet Bandwidths Messages-API, Applications und Message-Callbacks Bird zu. Folgen Sie dem [Hauptleitfaden zur Migration](/docs/guides/sms/migrate) der Reihe nach und verwenden Sie diese Zuordnungen für die Schritte 3, 4 und 5.

Zwei Unterschiede prägen die gesamte Portierung. Bandwidth verteilt den Kanal auf zwei Hosts: Der Versand liegt auf dem Messaging-Host unter Ihrem Account-Pfad, authentifiziert über HTTP Basic, während die 10DLC-Registrierung auf dem API-Haupthost liegt. Bird fasst Versand, Registrierung und Zustellungsevents unter einer Basis-URL und einem Bearer-Key zusammen. Und die `applicationId` bei jedem Bandwidth-Send enthält die Callback-Konfiguration; Bird hat kein entsprechendes Objekt, weil Callbacks eine Workspace-Subscription sind und keine Eigenschaft der Nachricht.

## Übergeben Sie dies an Ihren Agenten

Verwenden Sie dieses Briefing in Ihrem Coding-Agenten. Es beginnt mit einer Bestandsaufnahme und erstellt einen überprüfbaren Migrationsplan, bevor Produktionsänderungen stattfinden.

```text
Help me migrate my SMS integration from Bandwidth 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/bandwidth.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 Bandwidth 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 Send-Call zuordnen

| Funktion             | Bandwidth                       | Bird                                                                          |
| -------------------- | ------------------------------- | ----------------------------------------------------------------------------- |
| Empfänger            | `to` (Array)                    | `to` (einer pro Request)                                                      |
| Absender             | `from`                          | `from`                                                                        |
| Inhalt               | `text`                          | `text`                                                                        |
| Callback-Routing     | `applicationId`                 | ein Workspace-Webhook, der die unten aufgeführten Zustellungsevents abonniert |
| Intent               | (keiner)                        | `category`, erforderlich bei Freitext                                         |
| Freitext-Label       | `tag` (ein String)              | `metadata`; `tags` nur, wenn Sie es benennen können                           |
| Roundtrip-Kontext    | eigener Store, nach ID geordnet | `metadata`: beliebige JSON, bei jedem Event zurückgegeben                     |
| Zustellpriorität     | `priority`                      | kein Äquivalent                                                               |
| Sichere Wiederholung | (nicht in deren Spezifikation)  | `Idempotency-Key`-Header                                                      |
| Medien               | `media`                         | kein Äquivalent: `media_urls` wird abgelehnt                                  |

Hinweise zur Portierung:

- **`to` wird von einem Array auf einen einzelnen Empfänger reduziert.** Bandwidth nimmt eine Liste entgegen; Bird sendet eine Nachricht pro Request. Eine Schleife ersetzt das Array, und jeder Aufruf kann seinen eigenen `Idempotency-Key` mitgeben.
- **Die `applicationId` entfällt, anstatt verschoben zu werden.** Sie existiert, um Bandwidth mitzuteilen, wohin Callbacks gepostet werden. Bei Bird ist das eine Workspace-Subscription, daher wird beim Send nichts davon benannt.
- **`tag` und `tags` sind nicht dasselbe Feld.** Bandwidths `tag` ist ein einzelner Freitext-String; Birds `tags` sind `{name, value}`-Paare, die zu Abfragedimensionen werden. Ein einzelner undurchsichtiger String wird in der Regel besser in `metadata` transportiert.
- **Nichts an der Messages-API entspricht `category`.** Entscheiden Sie pro Nachrichtentyp, ob es `transactional`, `marketing`, `authentication` oder `service` ist.

## Opt-outs übernehmen

**Es gibt keine Liste zum Exportieren, und genau das ist das Ergebnis – keine Lücke in diesem Leitfaden.**

Außerhalb von Toll-Free pflegt Bandwidth keine Opt-in- oder Opt-out-Listen für Sie. Deren eigene Dokumentation sagt es klar: Die Verantwortung, die Befehle zu beachten und die Listen zu führen, liegt beim Kunden. Toll-Free ist die Ausnahme, wo `STOP` und seine Varianten auf der Netzwerkebene unabhängig von Ihrer Konfiguration durchgesetzt werden; Long Codes und Short Codes erhalten keine solche Behandlung.

Bei dieser Migration ist die maßgebliche Liste also bereits Ihre. Es ist eine Tabelle, ein Flag an einem Kontaktdatensatz oder eine Prüfung, die Ihr Sendepfad vor dem Aufruf der API ausführt, und die erste Aufgabe besteht darin, festzustellen, welche davon maßgeblich ist – statt einen Export von irgendwem anzufordern. Ihr eigenes Eingangs-Nachrichten-Log ist der Fallback: Einige Opt-outs begannen als eingehende Nachrichten, andere kamen über den Support, Formulare oder einen anderen Präferenzkanal.

Importieren Sie dann über die [Suppression-Schleife](/docs/guides/sms/migrate#4-carry-over-your-opt-out-list). Eine Bird-Suppression ist ein Absender-Abonnenten-Paar; ein Abonnent, den Sie bei drei Absendern gestoppt haben, ergibt also drei Datensätze. [Suppressions lesen und verwalten](/docs/guides/sms/opt-outs-and-keywords#reading-and-managing-suppressions) enthält den Befehl und erklärt, warum eine manuelle Suppression jede Kategorie einschließlich transaktionaler blockiert.

**Entscheiden Sie, wem die Liste nach dem Cutover gehört, denn hier gewinnen Sie etwas und können den Überblick verlieren.** Bird beantwortet Stopp-Keywords aus seinem eigenen länderspezifischen Katalog, sodass die Plattform Suppressions für Sie pflegt, sobald Sie hier senden: Ein Abonnent, der `STOP` schreibt, erzeugt einen Datensatz mit dem Grund `keyword_stop`, ohne dass Ihre Anwendung etwas tut. Wenn Ihr Code eine eigene Liste führt und weiter durchsetzt, driften beide auseinander, und das typische Symptom ist ein Abonnent, der auf einer Seite fortgesetzt hat und auf der anderen nicht. Halten Sie den Eigentümer der Zielgruppenpräferenzen explizit fest und synchronisieren Sie relevante Änderungen bewusst. Absender-Suppressions allein decken keine workspaceweiten Präferenzen oder Anfragen außerhalb des Keyword-Katalogs ab. Gründe stapeln sich, anstatt zusammengeführt zu werden: Ein Paar, das Sie als `manual` importiert haben und das später `STOP` schreibt, hält zwei Datensätze, und Nachrichten bleiben gestoppt, bis beide beendet sind.

## Zustellstatus übersetzen

Verwenden Sie diese Tabelle, um Lifecycle-Konzepte zu vergleichen, nicht um Events mechanisch umzubenennen. Bird wählt ein Fehler-Event anhand des gemeldeten Status und Grundes. Ein abgelehnter API-Request erzeugt keine Nachricht; eine Ablehnung nach Annahme kann `sms.rejected` erzeugen, einschließlich einer Carrier-Ablehnung. Fehlende Zustellnachweise bleiben unbekannt. Bewahren Sie den rohen Provider-Status und -Code neben Ihrem normalisierten Ergebnis auf.

| Ergebnis                             | Bandwidth-Callback-Typ        | Bird                                    |
| ------------------------------------ | ----------------------------- | --------------------------------------- |
| API hat die Nachricht angenommen     | die `202`-Antwort, kein Event | `sms.accepted`                          |
| An den Carrier übergeben             | `message-sent`                | `sms.sent`                              |
| Carrier hat Zustellung bestätigt     | `message-delivered`           | `sms.delivered`                         |
| Hat den Carrier nie erreicht         | `message-failed`              | `sms.rejected`                          |
| Carrier hat abgelehnt                | `message-failed`              | `sms.failed`                            |
| Carrier hat Nichtzustellung gemeldet | `message-failed`              | `sms.undelivered`                       |
| Carrier hat aufgegeben               | `message-failed`              | `sms.expired`                           |
| Request bei Eingang abgelehnt        | Request-Fehler                | HTTP-Fehler; keine Nachricht oder Event |

Zwei Punkte in dieser Tabelle sollten Sie umsetzen, statt darüber hinwegzulesen.

Bauen Sie die Behandlung von Endzuständen auf Basis von Birds Nachrichtendatensatz und Event-Zeitstempeln neu auf. Webhook-Zustellungen können sich wiederholen oder in falscher Reihenfolge eintreffen; Ihr Consumer darf nicht von einer einzigen Zustellung eines letzten Callbacks ausgehen. Ein Rejected-Status und ein Delivery-Failed-Status können unterschiedliche Bird-Events auslösen, selbst wenn beide vom Downstream stammen.

`message-sending` hat keine Zeile, weil es nur für MMS gilt, und `message-read` ist nur für RBM; keines davon wird bei SMS ausgelöst.

Zwei Mechanismen ändern sich mit den Namen:

- **Subscriptions ersetzen die Application.** Bandwidth leitet Callbacks anhand der `applicationId` weiter, die in der Nachricht angegeben ist. Bird liefert an Endpoints, die Ihr Workspace registriert, jeweils abonniert auf die gewünschten Event-Typen. Ein neuer Consumer ist also eine neue Subscription statt einer neuen Application und eines Redeployments.
- **Standard Webhooks ersetzt deren Callback-Authentifizierung.** Bird sendet JSON, signiert nach [Standard Webhooks](https://www.standardwebhooks.com); ersetzen Sie die Verifikation durch das Verfahren in [Webhooks & Events](/docs/guides/webhooks#verify-signatures).

Registrieren Sie den Endpoint einmalig und geben Sie die Event-Typen an, die Ihr Handler empfangen soll: Die oben aufgeführten `sms.*`-Events sind die Liste, die Sie abonnieren, und es gibt keinen Wildcard, der sie vertritt. [Endpoint erstellen](/docs/guides/webhooks#create-an-endpoint) enthält den Befehl und das Einzige, was beim ersten Aufruf stimmen muss: das Signing-Secret speichern, das die Antwort genau einmal anzeigt.

## Cutover

[Destinations](/docs/guides/sms/migrate#1-enable-your-destination-countries), [Sender](/docs/guides/sms/migrate#2-set-up-a-sender) und die [Traffic-Rampe](/docs/guides/sms/migrate#6-test-against-simulated-destinations) sind anbieterunabhängig und im Hauptleitfaden beschrieben. Zwei Bandwidth-spezifische Punkte gehören auf den Cutover-Plan: Ihre 10DLC-Brand und -Kampagne sind über Bandwidth bei The Campaign Registry registriert und werden nicht automatisch zu Bird-Registrierungen. Bestätigen Sie das anwendbare Migrations- oder Registrierungsverfahren, bevor Sie kostenpflichtige Arbeit einreichen. Nummern, die Sie bei Bandwidth besitzen, erfordern eine Portierung, die der Support nach seinem eigenen Zeitplan einrichtet – nicht nach Ihrem.

Für die Bird-seitigen Anforderungen beginnen Sie mit [Für 10DLC registrieren](/docs/guides/sms/10dlc): Die Seite erklärt, was jedes Feld bedeutet, welche Entity-Typen die Registry anerkennt und welcher Requirements-Call Ihnen sagt, was Sie vor dem Erstellen der Brand angeben müssen – dem kostenpflichtigen Schritt.

## Nächste Schritte

- [Bird und Bandwidth für SMS vergleichen](/products/sms/compare/bird-vs-bandwidth): Produktbewertung und Migrationsüberlegungen

- [SMS senden](/docs/guides/sms/sending-sms): die Payload, auf die Sie portieren, vollständig
- [Opt-outs und Keywords](/docs/guides/sms/opt-outs-and-keywords): Keyword-Abdeckung pro Land und Suppression-Verwaltung
- [SMS-Events](/docs/guides/sms/events): das Event-Vokabular, auf das Ihr Callback-Handler umzieht
- [Webhooks & Events](/docs/guides/webhooks): Endpoint-Setup und Standard-Webhooks-Verifikation

## 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)
