Migrer SMS depuis Infobip

Transmettez ceci à votre agent

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

Mapper l'appel d'envoi

• Trois niveaux deviennent zéro. L'imbrication existe pour transporter plusieurs messages et plusieurs destinations dans une seule requête. Pour envoyer un message à une personne, Bird prend les trois champs au niveau racine, donc le constructeur qui assemble les tableaux est supprimé plutôt que traduit.
• callbackData est plus grand que metadata. Infobip accepte jusqu'à 4 000 caractères et les renvoie dans le rapport de livraison. metadata de Bird est limité à 2 Ko sérialisé et est renvoyé à chaque événement du message, pas seulement au dernier. L'écho est le meilleur accord ; la limite ne l'est pas, donc tout ce qui approche le plafond doit être réduit à une clé que vous pouvez rechercher plutôt que transporté en entier.
• campaignReferenceId est un contexte de reporting, pas une migration de campagne. Les tags de Bird sont des paires {name, value} qui deviennent des dimensions de requête, vous permettant de découper les statistiques par campagne comme avant. Ce qui ne vient pas avec eux est un objet campagne : un tag ne crée ni ne configure un broadcast. Évaluez le workflow de campagne séparément lorsque vous migrez des campagnes d'audience.
• campaignReferenceId n'est pas une clé d'idempotence. Infobip le définit comme un identifiant pour suivre la performance d'une campagne, donc il regroupe mais ne déduplique pas. Si vous comptiez dessus pour sécuriser un réessai, vous n'étiez pas couvert ; c'est l'en-tête Idempotency-Key qui remplit ce rôle ici.
• Rien ne correspond à category. Les options de message d'Infobip couvrent la validité, la fenêtre de livraison, le flash et les paramètres régionaux, et aucune d'entre elles ne déclare pourquoi le message est envoyé. Décidez par type de message s'il s'agit de transactional, marketing, authentication ou service.
• Deux champs d'option n'ont pas de correspondance. validityPeriod est réservé et répond à 422 SMSUnsupportedFeature ; deliveryTimeWindow n'a pas de contrepartie, donc les fenêtres de planification passent dans votre propre dispatcher.

Transférer les désinscriptions

Traduire les statuts de livraison

• Les abonnements remplacent les webhooks par message. Infobip nomme un webhook sur chaque message, donc la destination est choisie par celui qui écrit l'appel, et le type de contenu est choisi avec. Bird livre JSON aux endpoints que votre espace de travail enregistre, chacun abonné aux types d'événements souhaités, donc un deuxième consommateur est un deuxième abonnement plutôt qu'une modification à chaque point d'appel.
• Vous perdez le choix par message, y compris le XML. Infobip permet à un message de choisir JSON ou XML et d'attacher jusqu'à 4 000 caractères de données de callback. Bird envoie uniquement du JSON, et callbackData devient metadata, qui est renvoyé à chaque événement de ce message et non uniquement sur le rapport.
• Le pull devient du push. Infobip vous permet de récupérer les rapports depuis un endpoint de rapports ainsi que de les recevoir. Bird n'a pas d'équivalent de polling pour les événements ; abonnez-vous, et lisez l'état du message via API lorsque vous en avez besoin à la demande.

Basculer

Étapes suivantes

• Comparer Bird et Infobip pour SMS : évaluation produit et considérations de migration
• Envoyer des SMS : le payload vers lequel vous portez, dans son 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 rapports migre
• Webhooks & événements : configuration des endpoints et vérification Standard Webhooks