Todo lo que hacemos para implementar e integrar Twilio, escrito al completo y actualizado para cómo funciona la plataforma en 2026. Cómo encaja la arquitectura de canales, seguimiento de entregas y callbacks de estado, OTP y verificación de identidad, conformidad 10DLC y A2P para los operadores estadounidenses, diseño de flujos Studio, contact center Flex, integración CRM y el modelo de compromiso que utilizamos. Sin vaguedades, sin arquitectura sin explicar.
Esta guía cubre el stack completo de Twilio, desde el primer mensaje hasta un contact center de nivel producción. Twilio es vasto y la documentación está dispersa, por lo que la mayoría de las implementaciones empiezan con lo básico y nunca alcanzan la fiabilidad o la postura de conformidad que necesitan. Lo que sigue es la arquitectura hacia la que construimos, en el orden que tiene sentido seguir, con diagramas para los flujos más difíciles de configurar bien la primera vez.
Twilio no es un producto único. Es una plataforma de primitivos de comunicación y la primera decisión es qué combinación necesita realmente tu caso de uso. Equivocarse en esa arquitectura al principio significa reconstruir la lógica de enrutamiento más adelante, por eso la mapeamos antes de escribir una línea de código.
Algunos principios rigen las decisiones. Primero, posee siempre la lógica de enrutamiento en tu propio código, no solo en la consola de Twilio, porque la configuración de la consola es difícil de versionar y probar. Segundo, trata los canales como fallbacks entre sí: si WhatsApp falla, cae en SMS; si SMS falla, cae en email o voz según la urgencia. Tercero, cada envío debe producir un evento de entrega que puedas almacenar, consultar y sobre el que generar alertas.
Los SMS programables son el producto Twilio más utilizado y el que tiene más modos de fallo. La propia API de envío es simple; la fiabilidad está en lo que construyes a su alrededor.
La elección entre un código largo, un código corto y un número gratuito depende del volumen, la geografía y el caso de uso. Los códigos cortos tienen el mayor throughput (100 mensajes por segundo) y pasan el filtrado de operadores de forma más fiable para envíos de alto volumen desde aplicaciones, pero requieren un proceso de aprovisionamiento de seis a ocho semanas y cuestan más operar. Los números gratuitos requieren un proceso de verificación separado pero ofrecen un camino más rápido hacia una entregabilidad fiable para volúmenes moderados. Los códigos largos son el punto de partida por defecto pero requieren el registro 10DLC para envíos hacia EE. UU., tratado en la sección de conformidad.
WhatsApp Business API a través de Twilio admite dos tipos de mensajes. Las plantillas pueden enviarse en cualquier momento y a cualquier usuario con consentimiento, pero deben ser pre-aprobadas por WhatsApp antes de su uso, lo que tarda uno a tres días por plantilla. Los mensajes de sesión pueden contener cualquier contenido pero deben enviarse dentro de las 24 horas del último mensaje del usuario. La arquitectura práctica para la mayoría de flujos de notificación es: enviar primero una plantilla; si el usuario responde, pasar a mensajes de sesión mientras la ventana esté abierta.
La aprobación de plantillas es el principal cuello de botella. Construye una biblioteca de plantillas antes del go-live y envía las aprobaciones con tiempo. Una plantilla rechazada hay que revisarla y reenviarla, lo que añade días. Mantén el texto específico y evita cualquier cosa que parezca un mensaje de marketing en una categoría de plantilla transaccional.
La mayoría de las implementaciones Twilio se saltan el seguimiento de entregas y lo pagan en tickets de soporte. El patrón es siempre el mismo: los mensajes salen, algunos fallan en silencio, los usuarios se quejan de que nunca recibieron su código o confirmación y el soporte no puede depurar porque no hay log de entrega.
La implementación requiere tres cosas: pasar una URL statusCallback en cada envío de mensajes, construir un endpoint webhook que reciba el POST y persistir los campos de estado (MessageSid, MessageStatus, ErrorCode, To, From) en tu base de datos. Twilio firma cada callback con un header de firma; valídalo en el endpoint para evitar actualizaciones de estado falsificadas. Una vez que tienes el log de entrega, puedes escribir un simple cron o event handler que consulte los mensajes bloqueados en "undelivered" tras cinco minutos y active un reintento en el próximo canal disponible.
Twilio Voice usa TwiML, un dialecto XML, para describir qué debe suceder cuando se conecta una llamada. La implementación más simple es un webhook que devuelve TwiML; la versión más sofisticada construye esa respuesta webhook dinámicamente según el número del llamante, la hora del día, la profundidad de la cola o el estado en el CRM.
Las llamadas inbound necesitan un número de teléfono aprovisionado en la consola de Twilio con una URL webhook que apunte a tu handler TwiML. Las llamadas outbound se inician a través de la API REST y del mismo modo dirigen a Twilio hacia una URL TwiML que controla el flujo de la llamada. Los patrones habituales incluyen: leer un mensaje y colgar (notificación automatizada), recoger una respuesta numérica y enrutar según corresponda (IVR), conectar a una sala de conferencia (llamada de equipo o soporte) o grabar la conversación y transcribirla.
Las grabaciones y transcripciones se almacenan en Twilio a menos que configures URLs de callback para recibirlas y almacenarlas tú mismo. Por razones de conformidad, especialmente en sectores con requisitos de consentimiento a la grabación, generalmente conviene transmitir las grabaciones a tu propio almacenamiento de inmediato y eliminarlas de Twilio con un intervalo corto.
Twilio Verify es un producto dedicado para contraseñas de un solo uso y autenticación de dos factores. Gestiona la generación del OTP, la entrega del código por SMS, WhatsApp o llamada de voz y la verificación del código en una sola API, lo que es un mejor punto de partida que construir la misma lógica sobre la API de mensajería pura.
El fraude de tarificación en flujos OTP es un riesgo real de coste. El ataque es simple: un bot envía a tu endpoint de inicio OTP miles de solicitudes usando números de tarificación premium en países con costes elevados por mensaje, disparando tu factura de Twilio sin introducir nunca un código. La solución es el rate limiting en tu lado antes de llamar a la API Verify, no dentro de Verify. Limita los intentos por número de teléfono por hora, agrega un CAPTCHA o reto invisible en el formulario web y establece límites de gasto en la consola de Twilio como cap de último recurso.
Twilio es propietaria de SendGrid y para el email en producción deberías usar directamente la API de SendGrid en lugar de enrutar el email a través de la API de mensajería central de Twilio. La distinción importa para la entregabilidad, ya que SendGrid gestiona IPs dedicadas, bounce management y alineación DKIM y DMARC, que la ruta de mensajería genérica de Twilio no proporciona.
La configuración mínima para email transaccional fiable es: una IP dedicada o compartida según el volumen, autenticación de dominio con registros SPF y DKIM en DNS, política DMARC al menos en p=none para empezar, un webhook de rebotes y bajas para suprimir envíos futuros a direcciones problemáticas y registro de eventos para tener un registro de entrega que corresponda a lo que los callbacks de estado de Twilio proporcionan para SMS.
Las plantillas en SendGrid están versionadas y pueden renderizarse en el servidor con sustitución dinámica de datos. Usa plantillas dinámicas para el correo transaccional para que el contenido pueda actualizarse sin un despliegue de código y mantén un fallback en texto plano para cada plantilla HTML porque una pequeña parte de los clientes de email y filtros de spam puntúan positivamente la presencia de texto plano.
Twilio Studio es una herramienta visual de arrastrar y soltar para construir flujos de comunicación: menús IVR, scripts de chatbot, captación de leads, recordatorios de citas con respuestas de confirmación y cualquier secuencia que se ramifique según la entrada del usuario o datos externos. Es valioso para no desarrolladores que necesitan modificar la lógica del flujo sin un despliegue y para flujos lo bastante complejos como para ser difíciles de leer como TwiML puro pero que no requieren código backend completo.
Studio ejecuta los flujos mediante widgets conectados entre sí con ramas condicionales. Los widgets de petición HTTP pueden llamar a tus propias APIs durante el flujo para buscar datos del cliente, escribir eventos en tu CRM o recuperar valores dinámicos. La salida de cualquier widget está disponible para los widgets siguientes mediante una sintaxis de variables. Esto hace posible construir flujos como: recibir un SMS inbound, buscar al remitente en tu CRM, ramificar según su estado y enviar una respuesta personalizada, todo sin escribir TwiML a mano.
La precaución operativa con Studio es el versionado. Los flujos publicados no se versionan automáticamente de una manera que se integre con git o los pipelines de despliegue estándar. Exporta el JSON del flujo en cada cambio y almacénalo en control de versiones para tener un camino de recuperación si un flujo publicado se modifica accidentalmente.
Twilio Flex es un contact center programable: una aplicación React que Twilio aloja y que puedes personalizar con plugins para construir paneles de agentes, reglas de enrutamiento, vistas de colas e integraciones CRM. Gestiona voz y mensajería inbound desde una sola interfaz y te da acceso al Twilio TaskRouter subyacente, que es el motor de enrutamiento que distribuye el trabajo a los agentes según habilidades, profundidad de cola y disponibilidad de workers.
La implementación estándar de Flex para un equipo de soporte cubre: aprovisionamiento del workspace y configuración de colas, escritura de un plugin que recupera los datos del cliente de tu CRM y los muestra como screen pop cuando llega una tarea, configuración del flujo de wrap-up para que los agentes puedan registrar una disposición y cerrar la tarea correctamente, y construcción de una wallboard que muestra la profundidad de cola y el estado de los agentes en tiempo real. Eso lleva una o dos semanas para un equipo de hasta veinte agentes en un caso de uso estándar.
Los casos más complejos son el enrutamiento multi-canal (voz, WhatsApp y chat desde la misma cola), el enrutamiento prioritario (los clientes VIP van a un grupo de habilidades dedicado) y el enrutamiento de desbordamiento (tras un umbral de profundidad de cola, enrutar a un flujo de voicemail o callback en lugar de dejar crecer los tiempos de espera). TaskRouter gestiona todos estos casos de forma nativa con configuración de workflows y atributos personalizados en tareas y workers.
10DLC (10-Digit Long Code) es el programa de operadores estadounidenses que exige a las empresas registrar su brand y las campañas de mensajería antes de enviar SMS A2P a escala en códigos largos. Sin registro, los operadores pueden filtrar tus mensajes y muchos lo hacen. Esta ha sido la principal causa de fallos inesperados en la entrega de SMS desde que el programa se volvió obligatorio en 2021.
El registro A2P se aplica a un conjunto más amplio de tipos de número. Los números gratuitos necesitan un proceso de verificación separado de Twilio para números gratuitos. Los códigos cortos requieren una solicitud dedicada a cada operador estadounidense y tardan seis a ocho semanas en aprovisionarse. Para los envíos internacionales fuera de EE. UU., distintos países tienen distintos requisitos de operador; los SMS del Reino Unido a la mayoría de operadores requieren pre-registro en un hub de mensajería y algunos países solo permiten SMS desde números locales.
Inicia el registro de conformidad con anticipación. Si estás construyendo un producto que enviará SMS a números estadounidenses, comienza el registro de brand y campaña 10DLC antes de tu fecha de go-live. La revisión del operador puede tardar hasta una semana y los rechazos añaden tiempo. Hacer correr tráfico no registrado en códigos largos no es una alternativa viable; el filtrado del operador destruirá silenciosamente tu tasa de entrega y no lo sabrás hasta que los usuarios empiecen a quejarse.
El patrón de integración más común es la sincronización bidireccional: tu app activa los envíos de Twilio según eventos y los callbacks de Twilio escriben el estado de entrega y las respuestas inbound de vuelta en tu app o CRM. La arquitectura más limpia usa un servicio de mensajería interno único al que se dirigen todas las partes de tu aplicación, que abstrae el SDK de Twilio detrás de tu propia interfaz y facilita agregar canales más adelante o cambiar de proveedor.
Para Zoho CRM en particular, los mensajes outbound pueden activarse mediante reglas de workflow y blueprints, y los mensajes inbound pueden actualizar campos de lead o contacto a través de funciones webhook personalizadas. El statusCallback de Twilio puede escribir en un módulo Twilio Log personalizado en Zoho a través de la API REST, dando a los agentes de soporte un historial completo de comunicaciones en cada registro de contacto sin salir del CRM. Un patrón similar se aplica a Salesforce, donde los platform events y los flows reemplazan a las reglas de workflow.
Las screen pop en un contexto de contact center, ya sea en Flex o directamente en el CRM, requieren una búsqueda en el momento en que llega la llamada o el mensaje: dado este número inbound, ¿cuál es el registro de contacto y cuál es su estado actual? Para voz esto ocurre en el webhook TwiML; para mensajería ocurre en el webhook del mensaje inbound. Ambos necesitan un endpoint de búsqueda rápida que pueda responder en menos de un segundo antes de que Twilio agote el tiempo de la conexión webhook.
Un compromiso Twilio es de alcance fijo, no un retainer abierto. La auditoría define el alcance; la implementación lo entrega en dos a cuatro sprints según cuántos canales e integraciones estén involucrados.
El primer sprint cubre los cimientos: un canal completamente implementado con callbacks de estado, logging de entrega, un endpoint webhook que valida las firmas de Twilio y la lógica de reintento inicial para los mensajes fallidos. Si los SMS hacia EE. UU. están en el alcance, el registro de brand y campaña 10DLC ocurre en paralelo al primer sprint para que esté aprobado y listo cuando el canal de la campaña entre en producción.
El segundo sprint cubre los canales adicionales y la implementación de Verify OTP si es necesario. Aquí también ocurre la integración CRM: conectar los disparadores de envío a los eventos de workflow, conectar los callbacks de entrega a los registros de contacto o negocio y construir el endpoint de búsqueda para las screen pop. La configuración del email SendGrid y la autenticación DKIM se ejecutan en este sprint si el email está en el alcance.
El tercer sprint, si es necesario, cubre los flujos Studio y Flex. Esto es normalmente su propio compromiso porque la configuración de Flex, el desarrollo de plugins y el diseño del workflow de TaskRouter requieren tiempo dedicado que se ejecuta en paralelo a la capa de mensajería en lugar de encima de ella.
Cada sprint sigue el mismo ciclo: auditar el estado actual, escribir una especificación lo bastante precisa para que tus desarrolladores puedan aplicarla sin adivinar, entregar y revisar la implementación y confirmar que los callbacks de estado, los logs de entrega y las alertas de error están activos antes de declarar el sprint completo.
Un único punto de contacto. Tienes un ingeniero que posee la relación, el calendario de entrega y cualquier escalado. Las especificaciones llegan en un formato estándar con criterios de aceptación que tu equipo puede comprobar. Todas las credenciales, claves API y runbooks son tuyos y se entregan el día que el compromiso se cierra.
Esa es la arquitectura completa. Cuando quieras que se aplique a tu configuración, el siguiente paso es una auditoría de comunicaciones gratuita: resultados reales sobre tus datos de entrega reales, en aproximadamente una semana, sin ningún compromiso.
Una auditoría gratuita sobre tus datos de entrega reales, las brechas cuantificadas y un alcance fijo para corregir lo que importa. Resultados en una semana.
Solicita una auditoría gratuita