SMS von Sinch migrieren

Diese Seite bildet Sinch' SMS API, Gruppen und Zustellberichte auf Bird ab. Folgen Sie dem Hauptmigrationsleitfaden der Reihe nach und verwenden Sie diese Zuordnungen für die Schritte 3, 4 und 5.

Zwei strukturelle Unterschiede prägen die Migration, und beide kosten mehr als die Feldumbenennungen. Sinch bindet den Versand an einen Service-Plan im URL-Pfad und sendet einen Batch, sodass selbst eine Nachricht an eine Person ein Array ist; Birds POST /v1/sms/messages nimmt einen Empfänger auf Ihrem regionalen Host mit einem Bearer-Key und ohne Plan-Segment entgegen. Und die US-Registrierung, die Sie nicht überspringen können, liegt auf einem anderen Host als der Versand, hinter einer anderen Credential-Familie – eine Codebasis, die Sinch für beides anspricht, erreicht also zwei verschiedene Stellen.

Übergeben Sie dies an Ihren Agenten

Verwenden Sie dieses Briefing in Ihrem Coding-Agenten. Es beginnt mit der Bestandsaufnahme und erzeugt einen überprüfbaren Migrationsplan, bevor etwas in Produktion geändert wird.

Codebeispiel

Help me migrate my SMS integration from Sinch 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/sinch.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 Sinch 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.

Versand-Call abbilden

Funktion	Sinch	Bird
Empfänger	to (Array oder eine Gruppen-ID)	to (einer pro Request)
Absender	from	from
Inhalt	body	text
Account-Routing	Service-Plan, im URL-Pfad	der Bearer-Key; kein Pfadsegment
Intent	(keiner)	category, erforderlich bei Freitext
Zustellberichte	delivery_report + callback_url, pro Batch	ein Workspace-Webhook; keine Steuerung pro Versand
Korrelation	client_reference	metadata, in jedem Event zurückgegeben
Filterbare Labels	(keine)	tags: {name, value}-Paare
Sichere Retries	(nicht dokumentiert)	Idempotency-Key-Header
Flash	flash_message	kein Äquivalent

Portierungshinweise:

Wählen Sie bewusst zwischen Einzelversand, Batch oder Broadcast. to ist bei Sinch ein Array und hier eine einzelne Nummer – verwenden Sie also Einzelversand oder den Batch-Endpunkt für bis zu 100 unabhängige Nachrichten. Eine Zielgruppenkampagne gehört in den Broadcast-Workflow. Ein Batch, der eine Gruppe benannte, erfordert zuerst die Auflösung der Mitgliedschaft; siehe den Opt-out-Abschnitt, denn es ist dasselbe Problem.
body wird zu text. Das ist die eine Umbenennung, die jede Aufrufstelle betrifft.
client_reference ist kein Idempotenz-Key. Sinch definiert ihn als Bezeichner, der dem Zustellbericht des Batches hinzugefügt wird – er korreliert also, dedupliziert aber nicht. Falls Sie sich darauf verlassen haben, einen Retry sicher zu machen, waren Sie nicht abgesichert; Idempotency-Key übernimmt hier diese Aufgabe.
Nichts entspricht category. Entscheiden Sie pro Nachrichtentyp, ob es transactional, marketing, authentication oder service ist.

Opt-outs übernehmen

Sinch speichert, wer dabei ist, und Bird muss wissen, wer draußen ist. Diese Umkehrung ist die eigentliche Arbeit.

Sinch verwaltet Empfänger als Gruppen, und eine Gruppe kann sich durch Keyword-Trigger automatisch aktualisieren: Ein Abonnent, der STOP sendet, wird aus der Gruppe entfernt, und ein Abonnent, der SUBSCRIBE sendet, wird hinzugefügt. Das Opt-out ist daher als Abwesenheit von einer Liste kodiert statt als Präsenz auf einer, und Abwesenheit lässt sich nicht exportieren: Eine Nummer, die in einer Gruppe fehlt, kann ein Opt-out durchgeführt haben, war vielleicht nie Mitglied oder wurde vor sechs Monaten durch einen Import entfernt.

Rekonstruieren Sie also, statt zu exportieren. Ihr eigenes Eingangs-Nachrichten-Log ist die zuverlässige Quelle, denn einige Opt-outs begannen als eingehende Nachrichten, während andere über den Support, Formulare oder einen anderen Präferenzkanal kamen – und diese Nachrichten existieren unabhängig davon, was die Gruppenmitgliedschaft jetzt anzeigt. Wo Sie neben der Gruppe ein eigenes Abmeldeflag geführt haben, ist dieses Flag bessere Evidenz als die Mitgliedschaft. Übernehmen Sie die rekonstruierte Liste in den Suppression-Loop, und zeigen Sie die Liste dem Account-Verantwortlichen, bevor Sie sie importieren: Ein falscher Eintrag hier unterdrückt stillschweigend Nachrichten, die Sie senden wollten.

Eine Bird-Suppression ist ein Paar aus Absender und Abonnent – ein Abonnent, den Sie bei drei Absendern sperren, ergibt also drei Einträge. Suppressions lesen und verwalten enthält den Befehl und den Grund, warum eine manuelle Suppression jede Kategorie einschließlich Transaktionsnachrichten blockiert.

Ab diesem Punkt beantwortet Bird die Stopp-Keywords selbst aus seinem länderspezifischen Katalog, sodass das Auto-Update-Verhalten der Gruppe kein Gegenstück hat, das Sie nachbauen müssen: Ein Abonnent, der STOP sendet, erzeugt eine Suppression, ohne dass Ihre Anwendung etwas tut. Gründe stapeln sich statt zu verschmelzen – ein Paar, das Sie als manual importiert haben und das später STOP sendet, hält zwei Einträge, und Nachrichten bleiben gesperrt, bis beide beendet sind.

Zustellstatus übersetzen

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

Sinchs Zustellbericht-Referenz umfasst queued, dispatched, delivered und mehrere verschiedene finale Fehlerzustände. Bewahren Sie den empfängerbezogenen Code und Status auf, wenn Sie Ihr Reporting übersetzen.

Sinch-Konzept	Bird-Integrationsentscheidung
Queued / Dispatched	Verfolgen Sie Annahme und Carrier-Übermittlung separat mit sms.accepted und sms.sent.
Delivered	Erfassen Sie das Netzergebnis über sms.delivered; es beweist nicht, dass die Nachricht gelesen wurde.
Failed / Rejected / Deleted	Prüfen Sie den gemeldeten Grund. Bird-Fehler-Events werden nicht durch bloßes Namens-Ersetzen ausgewählt.
Aborted / Expired / Cancelled	Bewahren Sie Ursache und Phase auf. Birds Einzelversand-API hat keinen Scheduling- oder Gültigkeitstimer, um diese Steuerungen nachzubilden.
Unknown	Lassen Sie das Ergebnis unbestimmt; zählen Sie eine fehlende interpretierbare Quittung nicht als Zustellung.

Birds sms.expired folgt einem Carrier-Ablaufbericht. Prüfen Sie Ihr bestehendes Ablauf- und Abbruchverhalten separat von diesem Event, statt jedes Timeout darauf abzubilden.

Beachten Sie auch, dass Zwischenstatus nur gemeldet werden, wenn der Batch per_recipient-Reporting angefordert hat – das ist Teil dessen, was sich im Folgenden ändert.

Sie verlieren die Steuerung der Zustellberichte pro Versand, und das verdient eine klare Ansage. Ein Sinch-Batch wählt seine eigene Berichtsgranularität und kann die Callback-URL des Service-Plans für diesen einzelnen Versand überschreiben. Bird bietet beides nicht: Reporting ist eine Workspace-Subscription, jedes abonnierte Event wird zugestellt, und es gibt keinen Pro-Nachrichten-Override. Falls Sie delivery_report verwendet haben, um gesprächige Kampagnen stumm zu halten, wandert dieses Filtern in Ihren Handler. Falls Sie die Reports einer Kampagne an einen anderen Endpunkt geroutet haben, wird daraus ein Endpunkt plus eine Verzweigung oder eine zweite Subscription.

Registrieren Sie den Endpunkt einmal und benennen Sie die Event-Typen, die Ihr Handler empfangen soll: Die oben aufgeführten sms.*-Events sind die Liste, die Sie abonnieren, und es gibt keinen Wildcard-Platzhalter dafür. Bird sendet JSON, signiert gemäß Standard Webhooks; Endpunkt erstellen enthält den Befehl und das Eine, das beim ersten Aufruf stimmen muss: das Signing-Secret, das die Antwort genau einmal anzeigt, sofort speichern.

Bird meldet einen Fehler mit einem standardisierten error-Code wie invalid_destination, content_rejected, provider_unavailable oder recipient_opted_out; die vollständige Liste finden Sie auf der Events-Seite.

Umstellung

Destinations, Absender und die Traffic-Rampe sind anbieterunabhängig und im Hauptleitfaden behandelt. Zwei Sinch-spezifische Punkte gehören auf den Umstellungsplan.

Ihre 10DLC-Marke und -Kampagne sind über Sinch bei The Campaign Registry registriert und werden nicht automatisch zu Bird-Registrierungen. Bestätigen Sie das anwendbare Migrations- oder Registrierungsverfahren, bevor Sie kostenpflichtige Arbeit in Auftrag geben. Hier vereinfacht sich auch die Integration. Bei Sinch liegt die Registrierungs-API auf einem separaten Host vom Versand und verwendet Projekt-Credentials statt des Service-Plan-Tokens, und Sinchs eigene Dokumentation sagt, dass HTTP Basic dort nur für Testzwecke gedacht und stark ratenbegrenzt ist – eine Produktionsintegration baut daher einen OAuth-Token-Flow dafür auf. Bei Bird liegt /v1/sms/10dlc/* neben /v1/sms/messages unter einer einzigen Basis-URL und einem einzigen Key, sodass dieser Token-Lifecycle entfällt statt portiert zu werden. Starten Sie mit Für 10DLC registrieren, das erklärt, was jedes Feld bedeutet, und den Requirements-Call beschreibt, der Ihnen sagt, was Sie angeben müssen, bevor Sie die Marke erstellen – das ist der kostenpflichtige Schritt.

Nummern, die Ihnen bei Sinch gehören, erfordern eine Portierung, die der Support organisiert – nach dessen Zeitplan, nicht nach Ihrem.

Nächste Schritte

Bird und Sinch für SMS vergleichen: Produktbewertung und Migrationsaspekte
SMS senden: der Payload, auf den Sie portieren, vollständig
Opt-outs und Keywords: Keyword-Abdeckung pro Land und Suppression-Verwaltung
SMS-Events: das Event-Vokabular, auf das Ihr Report-Handler umzieht
Webhooks & Events: Endpunkt-Einrichtung und Standard-Webhooks-Verifizierung