Migrer les SMS depuis Bird Connectivity Platform

L’API de Bird Connectivity Platform est accessible à rest.messagebird.com. Vous la connaissez peut-être sous le nom d’API MessageBird. Cette page en présente les correspondances avec Bird. Suivez le guide principal de migration dans l’ordre et utilisez ces correspondances pour les étapes 3, 4 et 5.

Les deux plateformes appartiennent à Bird ; c’est l’API qui change. Trois différences concernent chaque appel. Les requêtes sont adressées à votre hôte régional, https://us1.platform.bird.com ou https://eu1.platform.bird.com, au lieu d’un hôte mondial unique. L’authentification utilise une clé API de type bearer (Authorization: Bearer bk_us1_…) au lieu de Authorization: AccessKey. Enfin, l’envoi est asynchrone : POST /v1/sms/messages renvoie 202 Accepted et le message est mis en file d’attente. Connectivity Platform renvoyait l’objet message avec un statut déjà associé à chaque destinataire.

Transmettre ces instructions à votre agent

Utilisez ces instructions dans votre agent de développement. Il commence par examiner votre intégration et produit un plan de migration à vérifier avant toute modification en production.

Help me migrate my SMS integration from Bird Connectivity Platform 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/connectivity-platform.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 Connectivity Platform numbers, prepare the human support port request and obtain authorization to send it. Read bird platform support 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.

Adapter l’appel d’envoi

Le champ rejeté est réservé et renvoie 422 SMSUnsupportedFeature.

Points à prendre en compte pour la migration :

• Le tableau de destinataires devient un appel par destinataire. Un appel Connectivity Platform contenant 50 destinataires devient 50 envois, ou un lot de messages indépendants. Le lot ne diffuse pas un même corps à tous les destinataires : chaque entrée contient son propre destinataire, son expéditeur et son texte.
• datacoding n’a pas d’équivalent, et ce choix est délibéré. Bird détecte l’encodage du corps et indique le nombre de segments dans le message. Si vous utilisez datacoding: auto pour conserver les messages en GSM-7, le comportement le plus proche est options.smart_encoding, qui applique la table de remplacement documentée de Bird. Il ne s’agit pas d’une translittération générale ; les caractères non pris en charge peuvent encore nécessiter un encodage Unicode.
• reference conserve son nom. Le champ reference de Bird accepte de 1 à 255 caractères et est repris dans chaque événement webhook. Le filtre ?reference= de la liste des messages recherche cette valeur exacte. Réservez-le à la valeur qui vous sert à retrouver les messages : placez tout autre contexte dans metadata, et utilisez tags pour les libellés ayant peu de valeurs distinctes, afin de filtrer les données et de ventiler les analyses.
• Les contenus binaires sont transférables vers binary ; les messages flash et la concaténation UDH ne le sont pas. Un envoi binary accepte un udh hexadécimal et data dans un seul segment, et nécessite la catégorie transactional. Si vous utilisez actuellement mclass ou typeDetails, contactez le support avant de planifier la bascule, et non après.
• Vous utilisez aussi l’API Verify de Connectivity Platform ? Cette migration constitue une tâche distincte avec son propre guide : Migrer Verify depuis un autre fournisseur.

Transférer les oppositions

Connectivity Platform vous laissait gérer les mots-clés d’arrêt, dans Flows ou dans votre propre application traitant les messages entrants. Bird assure cette gestion : il reconnaît les mots-clés d’arrêt, de reprise et d’aide sur vos numéros dans les pays pris en charge, enregistre la suppression et l’applique à chaque envoi. Ne retirez un ancien gestionnaire qu’après avoir confirmé que le catalogue de Bird couvre son comportement et que votre gestion globale des préférences fonctionne toujours.

La liste, elle, doit être conservée. Exportez vos données actuelles sous forme de paires associant le numéro de l’abonné à l’expéditeur auquel il s’est opposé. Importez-les au moyen de la boucle de suppression avant votre premier envoi en production. Si vous ne conserviez qu’une liste globale d’abonnés opposés aux envois, importez chaque abonné une fois pour chaque expéditeur que vous utilisez encore.

Adapter les rapports de statut

Ce tableau compare les étapes du cycle de vie ; il ne suffit pas de renommer les événements mécaniquement. Bird choisit un événement d’échec à partir du statut et du motif signalés. Une requête API refusée ne crée aucun message. Un rejet après acceptation peut produire sms.rejected, y compris en cas de rejet par un opérateur. Sans preuve de livraison, le résultat reste inconnu. Conservez le statut et le code bruts du fournisseur avec votre résultat normalisé.

Le mécanisme de livraison change davantage que le vocabulaire :

• Les requêtes POST JSON signées remplacent les callbacks GET reportUrl. Les rapports de statut arrivaient sous forme de requêtes GET, avec le résultat dans les paramètres d’URL (status, statusReason, statusErrorCode, mccmnc, price[amount]). Bird envoie par POST un événement JSON aux points de terminaison enregistrés dans votre espace de travail, ou à l’URL de callback de l’envoi, signé selon Standard Webhooks. Le gestionnaire doit être réécrit ; un changement d’URL ne suffit pas.
• La corrélation ne dépend plus de reference. Un rapport de statut n’était utile que si vous aviez défini une référence. Un événement Bird contient toujours sms_id, les deux numéros, ainsi que vos metadata, tags et reference repris tels quels.
• Les règles de nouvelle tentative diffèrent. Connectivity Platform retentait jusqu’à 10 fois l’envoi d’un rapport ayant échoué. Les événements de Bird sont livrés au moins une fois, sans ordre garanti. Dédupliquez-les avec l’en-tête webhook-id et triez-les selon le timestamp du contenu.
• Rapprochez les coûts à partir du message et de la facturation. Le rapport Connectivity Platform contenait price[amount] et price[currency]. Consultez le coût enregistré du message avec GET /v1/sms/messages/{id} et rapprochez les frais de la facturation. L’API Stats fournit des mesures de livraison, pas un total de facturation faisant autorité.

Les messages entrants suivent le même principe : abonnez votre espace de travail une seule fois à sms.received, au lieu d’associer chaque numéro à une URL.

Effectuer la bascule

Les destinations, les expéditeurs et la montée en charge progressive du trafic sont indépendants du fournisseur et décrits dans le guide principal. Anticipez le traitement de vos expéditeurs : les identifiants alphanumériques sont recréés ici et enregistrés à nouveau lorsque le pays l’exige. Les numéros que vous détenez sur Connectivity Platform font l’objet d’un portage organisé par le support, et non d’un simple changement de paramètre.

Étapes suivantes

• Découvrir Bird SMS : parcours produit et possibilités d’intégration

• Envoyer des SMS : le contenu complet des requêtes vers lesquelles vous migrez

• Oppositions et mots-clés : les réponses prises en charge par Bird et la gestion des suppressions

• Événements SMS : le vocabulaire des événements à utiliser dans votre gestionnaire de statuts

• Webhooks et événements : configuration des points de terminaison et vérification Standard Webhooks