Migrar SMS desde Infobip

Pasa esto a tu agente

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.

Mapear la llamada de envío

• Tres niveles pasan a ninguno. El anidamiento existe para llevar muchos mensajes y muchos destinos en una solicitud. Para enviar un mensaje a una persona, Bird toma los tres campos en el nivel superior, así que el builder que arma los arrays se elimina en lugar de traducirse.
• callbackData es más grande que metadata. Infobip acepta hasta 4000 caracteres y lo devuelve en el informe de entrega. metadata de Bird tiene un límite de 2 KB serializado y se repite en cada evento del mensaje, no solo en el terminal. La repetición es mejor trato; el límite no, así que todo lo que se acerque al tope debe recortarse a una clave que puedas consultar en lugar de enviarse completo.
• campaignReferenceId es contexto de reportes, no una migración de campaña. Los tags de Bird son pares {name, value} que se convierten en dimensiones de consulta, para que puedas segmentar analíticas por campaña como lo hacías. Lo que no incluyen es un objeto de campaña: una etiqueta no crea ni configura un envío masivo. Evalúa el flujo de campaña por separado cuando migres campañas de audiencia.
• campaignReferenceId no es una clave de idempotencia. Infobip lo define como un ID para rastrear el rendimiento de una campaña, así que agrupa pero no deduplica. Si dependías de él para hacer seguro un reintento, no estabas cubierto; el encabezado Idempotency-Key es lo que cumple esa función aquí.
• Nada corresponde a category. Las opciones de mensaje de Infobip cubren validez, ventana de entrega, flash y configuraciones regionales, y ninguna declara por qué se envía el mensaje. Decide por tipo de mensaje si es transactional, marketing, authentication o service.
• Dos campos de opciones no tienen destino. validityPeriod está reservado y responde a 422 SMSUnsupportedFeature; deliveryTimeWindow no tiene contraparte, así que las ventanas de programación pasan a tu propio dispatcher.

Trasladar las cancelaciones de suscripción

Traducir estados de entrega

• Las suscripciones reemplazan los webhooks por mensaje. Infobip nombra un webhook en cada mensaje, así que el destino lo elige quien escribe la llamada, y el tipo de contenido se elige con él. Bird entrega JSON a endpoints que tu espacio de trabajo registra, cada uno suscrito a los tipos de evento que desea, así que un segundo consumidor es una segunda suscripción en lugar de un cambio en cada punto de llamada.
• Pierdes la elección por mensaje, incluido XML. Infobip permite que un mensaje elija JSON o XML y adjunte hasta 4000 caracteres de datos de callback. Bird envía solo JSON, y callbackData se convierte en metadata, que se repite en cada evento de ese mensaje en lugar de solo en el informe.
• Pull se convierte en push. Infobip te permite obtener informes desde un endpoint de reportes además de recibirlos. Bird no tiene un sondeo equivalente para eventos; suscríbete y lee el estado del mensaje a través de API cuando lo necesites bajo demanda.

Corte de migración

Próximos pasos

• Comparar Bird e Infobip para SMS: evaluación de producto y consideraciones de migración
• Enviar SMS: el payload al que estás migrando, completo
• Cancelaciones de suscripción y palabras clave: cobertura de palabras clave por país y gestión de supresiones
• Eventos de SMS: el vocabulario de eventos al que migra tu handler de reportes
• Webhooks y eventos: configuración de endpoints y verificación de Standard Webhooks