Migrer SMS depuis Plivo

Transmettez ceci à votre agent

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

• Un UUID de Powerpack devient une simple valeur d'expéditeur. Plivo résout le pool de numéros, l'expéditeur persistant et la présence locale derrière l'UUID. Bird prend l'expéditeur lui-même dans from, choisissez-le à chaque envoi, ou utilisez un envoi par template, qui sélectionne un expéditeur valide pour la destination et rejette from.
• type n'a pas d'équivalent car le endpoint le porte déjà. Plivo sélectionne le canal par requête ; les endpoints SMS, WhatsApp et autres canaux de Bird sont séparés. Un code qui change type à l'exécution se divise en appels à différents endpoints.
• Rien dans l'API Message API ne correspond à category. Décidez par type de message s'il s'agit de transactional, marketing, authentication ou service. Le trafic d'authentification en particulier doit être étiqueté comme tel plutôt que laissé dans un contexte marketing par défaut.
• Examinez la sémantique de réessai séparément. La référence d'envoi de Plivo ne documente ni clé d'idempotence ni mécanisme de déduplication, un timeout vous laisse donc dans l'incertitude. Envoyez l'en-tête Idempotency-Key dès le premier portage pour réduire le risque de requêtes dupliquées dans la fenêtre de rejeu de trois heures ; ce n'est pas une garantie de livraison exactement une fois.

Transférer les désinscriptions

Convertir les statuts de livraison

• Les endpoints remplacent les URL de callback par message. Plivo prend un url à chaque envoi, la destination est donc choisie par celui qui écrit l'appel. Bird livre aux endpoints enregistrés par votre espace de travail, chacun abonné aux types d'événements souhaités, un nouveau consommateur est donc un nouvel abonnement plutôt qu'une modification à chaque point d'appel.
• Des posts JSON signés remplacent un callback GET, si c'est ce que vous aviez choisi. Le champ method de Plivo sélectionne GET ou POST pour l'accusé de réception ; Bird envoie (POST) un événement JSON et ne propose pas de GET. Si vous aviez défini method=GET, votre handler lit le résultat dans les paramètres de chaîne de requête, et ce handler doit être réécrit plutôt que simplement réenregistré. Il en va de même un guide plus loin, sur le chemin Connectivity Platform.
• Un seul schéma de signature remplace trois en-têtes. Plivo signe les callbacks avec X-Plivo-Signature-V2, X-Plivo-Signature-Ma-V2 et X-Plivo-Signature-V2-Nonce. Bird envoie JSON signé selon Standard Webhooks, le vérificateur est donc remplacé et non ajusté : substituez-le par la recette dans Webhooks & events.

Basculer

Étapes suivantes

• Comparer Bird et Plivo pour SMS : évaluation produit et considérations de migration
• Envoyer des SMS : le payload vers lequel vous portez, en intégralité
• Désinscriptions et mots-clés : couverture des mots-clés par pays et gestion des suppressions
• Événements SMS : le vocabulaire d'événements vers lequel votre handler de callback migre
• Webhooks & events : configuration du endpoint et vérification Standard Webhooks