# Migrer SMS depuis Sinch

Cette page fait correspondre SMS API, les groupes et les accusés de réception de Sinch avec Bird. Suivez le [guide de migration principal](/docs/guides/sms/migrate) dans l'ordre et utilisez ces correspondances pour les étapes 3, 4 et 5.

Deux différences structurelles conditionnent le portage, et toutes deux coûtent plus que les renommages de champs. Sinch indexe l'envoi sur un service plan dans le chemin d'URL et envoie un **lot** (batch), si bien qu'un message à une seule personne reste un tableau ; le endpoint [`POST /v1/sms/messages`](/docs/api/reference/create-sms-message) de Bird prend un seul destinataire sur votre hôte régional avec une clé bearer, sans segment de plan. Et l'enregistrement US que vous ne pouvez pas ignorer se trouve sur un hôte différent de celui de l'envoi, derrière une autre famille d'identifiants, si bien qu'un code qui appelle Sinch pour les deux atteint en réalité deux endroits distincts.

## Transmettez ceci à votre agent

Utilisez ce brief dans votre agent de codage. Il commence par une phase de découverte et produit un plan de migration révisable avant toute modification en production.

```text
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.
```

## Faire correspondre l'appel d'envoi

| Fonction            | Sinch                                       | Bird                                                       |
| ------------------- | ------------------------------------------- | ---------------------------------------------------------- |
| Destinataire        | `to` (tableau, ou un ID de groupe)          | `to` (un par requête)                                      |
| Expéditeur          | `from`                                      | `from`                                                     |
| Corps               | `body`                                      | `text`                                                     |
| Routage du compte   | service plan, dans le chemin d'URL          | la clé bearer ; aucun segment de chemin                    |
| Intention           | (aucun)                                     | `category`, requis sur le texte libre                      |
| Accusé de réception | `delivery_report` + `callback_url`, par lot | un webhook d'espace de travail ; pas de contrôle par envoi |
| Corrélation         | `client_reference`                          | `metadata`, renvoyé sur chaque événement                   |
| Libellés filtrables | (aucun)                                     | paires `tags` : `{name, value}`                            |
| Réessais sûrs       | (aucun documenté)                           | en-tête `Idempotency-Key`                                  |
| Flash               | `flash_message`                             | pas d'équivalent                                           |

Notes de portage :

- **Choisissez délibérément un envoi unitaire, un lot ou une diffusion.** `to` est un tableau chez Sinch et un numéro unique ici ; utilisez donc des envois unitaires ou le endpoint de lot pour un maximum de 100 messages indépendants. Une campagne destinée à une audience relève du [workflow de diffusion](/products/sms/marketing/campaigns). Un lot qui désignait un groupe nécessite que l'appartenance soit résolue au préalable ; consultez la section sur les désinscriptions, car c'est le même problème.
- **`body` devient `text`.** C'est le seul renommage qui touche chaque point d'appel.
- **`client_reference` n'est pas une clé d'idempotence.** Sinch le définit comme un identifiant ajouté à l'accusé de réception du lot : il corrèle mais ne déduplique pas. Si vous comptiez dessus pour sécuriser un réessai, vous n'étiez pas couvert ; c'est `Idempotency-Key` qui remplit ce rôle ici.
- **Rien ne correspond à `category`.** Décidez par type de message s'il s'agit de `transactional`, `marketing`, `authentication` ou `service`.

## Reporter les désinscriptions

**Sinch enregistre qui est inscrit, et Bird a besoin de savoir qui est désinscrit.** Cette inversion est le cœur du travail.

Sinch gère les destinataires sous forme de groupes, et un groupe peut se mettre à jour automatiquement à partir de mots-clés : un abonné qui envoie `STOP` est retiré du groupe, et un abonné qui envoie `SUBSCRIBE` y est ajouté. La désinscription est donc encodée comme une _absence_ d'une liste plutôt qu'une présence sur une autre, et l'absence n'est pas exportable : un numéro absent d'un groupe peut s'être désinscrit, n'avoir jamais été inscrit, ou avoir été supprimé par un import il y a six mois.

Reconstruisez plutôt qu'exporter. Votre propre journal de messages entrants est la source fiable, car certaines désinscriptions ont commencé par des messages entrants, tandis que d'autres sont passées par le support, des formulaires ou un autre canal de préférences, et ces messages existent quel que soit l'état actuel de l'appartenance au groupe. Si vous conserviez votre propre indicateur de désinscription à côté du groupe, cet indicateur est une meilleure preuve que l'appartenance. Importez la liste reconstruite dans la [boucle de suppression](/docs/guides/sms/migrate#4-carry-over-your-opt-out-list), et montrez la liste au responsable du compte avant de l'importer : une entrée erronée ici bloque silencieusement des messages que vous aviez l'intention d'envoyer.

Une suppression Bird est une paire expéditeur-abonné : un abonné que vous bloquez sur trois expéditeurs représente donc trois enregistrements. [Lire et gérer les suppressions](/docs/guides/sms/opt-outs-and-keywords#reading-and-managing-suppressions) contient la commande, ainsi que la raison pour laquelle une suppression manuelle bloque toutes les catégories, y compris les messages transactionnels.

Une fois arrivé ici, Bird répond lui-même aux mots-clés d'arrêt à partir de son propre catalogue par pays ; le comportement de mise à jour automatique du groupe n'a donc pas d'équivalent à reconstruire : un abonné qui envoie `STOP` produit une suppression sans que votre application n'intervienne. Les raisons s'empilent au lieu de fusionner : une paire que vous avez importée comme `manual` et qui envoie ensuite `STOP` détient deux enregistrements, et les messages restent bloqués tant que les deux n'ont pas pris fin.

## Convertir les statuts de livraison

Utilisez ce tableau pour comparer les concepts de cycle de vie, pas pour renommer mécaniquement les événements. Bird choisit un événement d'échec à partir du statut et de la raison signalés. Une requête API refusée ne crée aucun message ; un rejet après acceptation peut produire `sms.rejected`, y compris un rejet par l'opérateur. Une absence de preuve de livraison reste inconnue. Conservez le statut brut du fournisseur et le code aux côtés de votre résultat normalisé.

La [référence des accusés de réception](https://developers.sinch.com/docs/sms/api-reference/sms/delivery-reports/getdeliveryreportbybatchid) de Sinch inclut queued, dispatched, delivered et plusieurs états d'échec final distincts. Conservez le code et le statut au niveau du destinataire lors de la conversion de vos rapports.

| Concept Sinch                       | Décision d'intégration Bird                                                                                                                        |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Queued` / `Dispatched`             | Suivez l'acceptation et la soumission à l'opérateur séparément avec `sms.accepted` et `sms.sent`.                                                  |
| `Delivered`                         | Enregistrez le résultat réseau via `sms.delivered` ; cela ne prouve pas la lecture.                                                                |
| `Failed` / `Rejected` / `Deleted`   | Inspectez la raison signalée. Les événements d'échec Bird ne se sélectionnent pas par simple substitution de nom.                                  |
| `Aborted` / `Expired` / `Cancelled` | Conservez la cause et l'étape. L'envoi unitaire API de Bird ne dispose pas de minuteur de planification ni de validité pour recréer ces contrôles. |
| `Unknown`                           | Laissez le résultat incertain ; ne comptez pas un accusé de réception absent ou non interprétable comme une livraison.                             |

`sms.expired` de Bird fait suite à un rapport d'expiration de l'opérateur. Examinez votre comportement actuel d'expiration et d'annulation indépendamment de cet événement plutôt que de faire correspondre chaque délai d'attente à celui-ci.

Notez également que les statuts intermédiaires ne sont signalés que lorsque le lot a demandé un rapport `per_recipient`, ce qui fait partie de ce qui change ci-dessous.

**Vous perdez le contrôle par envoi des accusés de réception, et cela mérite d'être dit clairement.** Un lot Sinch choisit sa propre granularité de rapport et peut surcharger l'URL de callback du service plan pour cet envoi seul. Bird ne propose ni l'un ni l'autre : le reporting est un abonnement au niveau de l'espace de travail, chaque événement souscrit est livré, et il n'y a pas de surcharge par message. Si vous utilisiez `delivery_report` pour mettre en sourdine les campagnes verbeuses, ce filtrage passe dans votre handler. Si vous routiez les rapports d'une campagne vers un endpoint différent, cela devient un seul endpoint avec un branchement, ou un second abonnement.

Enregistrez le endpoint une seule fois en nommant les types d'événements que votre handler attend : les événements `sms.*` ci-dessus sont la liste à laquelle souscrire, et il n'existe pas de joker pour les remplacer. Bird envoie JSON signés selon [Standard Webhooks](https://www.standardwebhooks.com) ; [Créer un endpoint](/docs/guides/webhooks#create-an-endpoint) contient la commande et la seule chose à réussir du premier coup : stocker le secret de signature que la réponse n'affiche qu'une seule fois.

Bird signale un échec avec un code `error` standardisé tel que `invalid_destination`, `content_rejected`, `provider_unavailable` ou `recipient_opted_out` ; la liste complète se trouve sur la [page des événements](/docs/guides/sms/events#failure-events).

## Basculer

Les [destinations](/docs/guides/sms/migrate#1-enable-your-destination-countries), les [expéditeurs](/docs/guides/sms/migrate#2-set-up-a-sender) et la [montée en charge du trafic](/docs/guides/sms/migrate#6-test-against-simulated-destinations) sont indépendants du fournisseur et couverts dans le guide principal. Deux éléments spécifiques à Sinch doivent figurer dans le plan de bascule.

Votre marque et campagne 10DLC sont enregistrées auprès de The Campaign Registry via Sinch et ne deviennent pas automatiquement des enregistrements Bird. Confirmez la procédure de migration ou d'enregistrement applicable avant de soumettre du travail payant. **C'est aussi là que l'intégration se simplifie.** Chez Sinch, l'enregistrement API se fait sur un hôte distinct de l'envoi et utilise des identifiants de projet plutôt que le token du service plan, et la propre documentation de Sinch indique que HTTP Basic y est destiné uniquement aux tests et fortement limité en débit ; une intégration de production construit donc un flux de token OAuth pour cela. Chez Bird, `/v1/sms/10dlc/*` se trouve aux côtés de `/v1/sms/messages` sous une seule URL de base et une seule clé : ce cycle de vie de token est donc supprimé, pas porté. Commencez par [S'enregistrer pour le 10DLC](/docs/guides/sms/10dlc), qui explique la signification de chaque champ et l'appel de vérification des prérequis qui vous indique quoi fournir avant de créer la marque, l'étape payante.

Les numéros que vous possédez chez Sinch nécessitent un portage que le support organise, selon son propre calendrier et non le vôtre.

## Étapes suivantes

- [Comparer Bird et Sinch pour SMS](/products/sms/compare/bird-vs-sinch) : évaluation produit et considérations de migration

- [Envoyer des SMS](/docs/guides/sms/sending-sms) : le payload vers lequel vous portez, dans son intégralité
- [Désinscriptions et mots-clés](/docs/guides/sms/opt-outs-and-keywords) : couverture des mots-clés par pays et gestion des suppressions
- [Événements SMS](/docs/guides/sms/events) : le vocabulaire d'événements vers lequel votre handler de rapports migre
- [Webhooks et événements](/docs/guides/webhooks) : configuration des endpoints et vérification 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)