Desafíos de arquitectura en la integración de WhatsApp API
    WhatsApp, Meta

    Desafíos de arquitectura en la integración de WhatsApp API

    7 Ene 20267 min de lecturaPor Adolfo Munizaga
    DesarrolloChatbot

    En Chile, si tu producto no habla por WhatsApp, prácticamente no existe. Lo que casi nadie dimensiona antes de partir es cuánto trabajo hay detrás: las capas del proveedor, el estado de cada conversación y las reglas que Meta pone encima.

    En Wovi pasamos de prototipos experimentales a implementaciones en producción con tráfico real, y queríamos dejar documentado un poco de ese viaje técnico.

    1. Abstracción del proveedor vs. implementación directa

    Nuestro punto de partida fue Twilio. La ventaja desde la ingeniería es el nivel de abstracción: su SDK de Node.js encapsula las llamadas a la API en funciones nativas y te ahorra la mitad del trabajo sucio. En proyectos donde el cliente pedía más agilidad y menos lock-in, evaluamos integradores más livianos que operan más cerca de la API original de Meta. Hoy tenemos ambos esquemas conviviendo en producción y cada uno hace sentido en escenarios distintos.

    SDK-LEVEL

    Vía SDK (ej: Twilio)

    No hay que armar rutas a mano: se trabaja con objetos y métodos del paquete. Menos boilerplate, más rapidez para arrancar.

    API-FIRST

    Integrador liviano

    Trabajo más cerca de los endpoints originales de Meta. Más visibilidad sobre el payload y menos magia escondida en el SDK.

    2. El ciclo de vida de una conversación: la ventana de 24 horas

    Uno de los retos técnicos más subestimados no es enviar el mensaje, es manejar la sesión según las reglas de Meta.

    Regla crítica de Meta

    Cualquier mensaje que la plataforma inicie de manera proactiva tiene que seguir el protocolo de plantillas aprobadas. Una vez que el usuario responde, se abre una "ventana de servicio" de 24 horas en la que sí podemos enviar texto libre. Después se cierra y volvemos al juego de plantillas.

    Serialización de parámetros

    A diferencia de las APIs REST convencionales, donde uno pasa variables con nombre, Meta usa parámetros indexados (con corchetes tipo 1, 2, 3). Eso obliga a dos cosas:

    • Gestión de orden: el código tiene que garantizar que la inyección de datos coincida exactamente con el índice definido al momento de aprobar la plantilla. Un orden distinto y el mensaje se cae o, peor, llega con datos cruzados.
    • Validación de medios: al implementar envío de códigos QR dinámicos para una empresa de atención al cliente, descubrimos que las imágenes en plantillas tienen que estar persistidas en el repositorio de Meta. Algunos integradores manejan archivos provisionales que expiran a los 30 días, lo que en producción es una bomba de tiempo.

    Para resolverlo, terminamos integrando directo con WhatsApp Manager y asegurando la persistencia del recurso multimedia desde ahí.

    3. Webhooks y lógica de estado: el desafío de las encuestas

    Cuando armamos la solución para una empresa de investigación de mercado, el problema dejó de ser "enviar mensajes" y pasó a ser manejo de flujos de estado.

    WhatsApp es asíncrono por naturaleza. Los webhooks notifican al servidor cada evento por separado: mensaje recibido, botón presionado, entrega confirmada. Si no tenemos una capa propia que reconstruya la conversación, terminamos respondiendo al revés o repitiendo preguntas.

    Arquitectura de estado que terminó funcionando

    1

    Conversational flow

    El servidor identifica en qué punto del flujo está cada usuario, usando su número de teléfono como llave.

    2

    State machine

    Una máquina de estados valida qué encuestas están activas, qué preguntas ya se respondieron y qué autorespuesta corresponde.

    4. La parte aburrida: costo por mensaje

    Algo que se ignora en la conversación de arquitectura es cómo termina la facturación. En las implementaciones más livianas trabajamos con un esquema de costos desacoplados:

    Componente Descripción
    Costos Meta El costo por conversación se paga directo a Meta vía Facebook Developers, sin intermediarios.
    Fee del integrador El integrador cobra una tasa mínima por la infraestructura de túneles y APIs, separada del costo del mensaje.

    Esto difiere del modelo Twilio, donde todo se paga centralizado en un solo dashboard. Es más cómodo, pero también es más fácil que se pierdan de vista los márgenes reales por mensaje.

    Conclusión

    No hay un ganador absoluto entre Twilio y un integrador más liviano. Twilio conviene cuando necesitas email, SMS y voz en el mismo lugar. El integrador liviano conviene cuando el caso es 100% WhatsApp y quieres ver el payload real que viaja a Meta.

    Lo que sí definimos de entrada: nuestra arquitectura es agnóstica al proveedor. Nosotros controlamos la lógica de negocio y los webhooks, y el cliente queda dueño de su cuenta de WhatsApp Business. Si mañana hay que cambiar de integrador, se cambia sin rehacer el sistema.

    Si ya tienes WhatsApp funcionando a medias y se te cae con volumen, escríbenos.

    Revisamos tu flujo actual, las plantillas y la máquina de estados, y te decimos qué hay que arreglar antes de escalar.

    Conversemos

    ¿Tu tecnología actual te genera más problemas que soluciones?

    Agenda una llamada con nuestro equipo y descubre cómo podemos ayudarte