Migrer les SMS depuis Bird Connectivity Platform

Transmettre ces instructions à votre agent

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

Adapter l’appel d’envoi

• 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 se répartit entre deux champs. Placez un identifiant interne dans metadata, qui est repris dans chaque événement webhook. Utilisez tags pour les libellés ayant peu de valeurs distinctes, afin de filtrer les données et de ventiler les analyses.
• Les messages flash, les contenus binaires et la concaténation UDH ne sont pas transférables. Si vous utilisez actuellement mclass ou typeDetails, contactez le support avant de planifier la bascule.
• 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

Adapter les rapports de statut

• 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, 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 et tags 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é.

Effectuer la bascule

É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 exclusions
• É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