WhatsApp y n8n: automatización para desarrolladores
Webhook de Meta, nodo Cloud API, las tres trampas que cuestan una tarde y cuándo aportar el criterio un agente con herramientas HTTP, catálogo o MCP.

n8n y WhatsApp encajan bien: un webhook de Meta entra a tu workflow, la lógica hace lo que sea y la Cloud API responde. Con dos nodos oficiales —WhatsApp Trigger y WhatsApp Business Cloud— montas el circuito en una tarde. Lo que la documentación reparte en páginas sueltas son los bordes: un solo webhook por app, la suscripción de la WABA y la ventana de 24 horas que falla en silencio.
Esta guía es la versión para desarrolladores: las piezas exactas, el circuito mínimo, las trampas que te cuestan una tarde y, al final, cuándo conviene que el criterio lo aporte un agente con herramientas —incluido el ángulo MCP.
Las dos piezas y sus credenciales
El nodo WhatsApp Trigger escucha eventos de la plataforma: mensajes, actualizaciones de cuenta, estado y calidad de plantillas. Se autentica por OAuth2 con el App ID y el App Secret de tu app de Meta. El nodo WhatsApp Business Cloud envía: mensajes, plantillas y gestión de medios, con credenciales de API key (token de acceso e ID de la cuenta de negocio). Dos nodos, dos credenciales, y detrás la misma API de WhatsApp Business que ya conoces.
El circuito mínimo
- EntradaWebhookMeta hace POST de cada mensaje a tu URL
- LógicaRuteoRamas por tipo de mensaje y por cliente
- AcciónIntegracionesCRM, base de datos o cualquier API por HTTP
- SalidaRespuestaTexto libre en ventana, plantilla fuera
- PausaEspera humanaSend and Wait detiene el flujo hasta confirmación
Meta entrega cada mensaje como POST a tu URL de webhook: emisor, texto o referencia de medio, marca de tiempo e identificador. A partir de ahí es un workflow normal: ramas por tipo de mensaje, consulta al CRM, lo que tu stack necesite. La salida vuelve por la Cloud API. Y hay una operación que cambia el juego: Send and Wait for Response, que envía un mensaje y detiene la ejecución hasta que la persona aprueba, responde texto libre o llena un formulario. Aprobación humana dentro del propio flujo, con límite de espera configurable.
Las tres trampas que te cuestan una tarde
Un solo webhook por app. Meta solo admite una URL de webhook por app: al pasar de la URL de test a la de producción, una sobrescribe la otra. Para probar un workflow publicado, despublica, prueba con la URL de test y vuelve a publicar.
Tu app debe estar suscrita a la WABA. Publicar el workflow registra tu webhook en la app, pero no suscribe la app a la cuenta de negocio. Si no lo está, los mensajes reales nunca llegan a n8n —y el evento de prueba del panel de Meta sí pasa, así que el test verde no descarta nada. Se comprueba con un GET a la API de subscribed_apps y se arregla con un POST sin body.
La ventana de 24 horas. Dentro de las 24 horas del último mensaje del cliente respondes en texto libre; fuera, solo plantillas aprobadas por Meta pasan. El workflow que siempre manda texto libre se ve perfecto en pruebas —que siempre ocurren segundos después del mensaje— y enmudece en el primer caso real de la madrugada. La forma robusta es una rama que mida la antigüedad del último mensaje y elija texto libre o plantilla.
Y si fuera de ventana toca enviar plantillas, las categorías importan para el precio: utilidad vs marketing tiene su propia guía.
Cuando el flujo necesita criterio, no solo ramas
Un workflow es pegamento determinista: brilla cuando el camino se conoce de antemano. Se queda corto cuando el cliente escribe lo que quiere, en su idioma, con contexto propio. Ahí hay dos arquitecturas, y no compiten: se reparten el trabajo.
| n8n | Agente IA | |
|---|---|---|
| Ramas fijas IF / Switch | ||
| Decide con lenguaje y RAG | ||
| Llama a tus webhooks y APIs | ||
| Cliente de servidores MCP | ||
| WhatsApp sin gestionar webhook |
La primera: mantener n8n como orquestador y darle un nodo de agente IA dentro del workflow, con su MCP Client Tool para llamar a servidores MCP externos. n8n es de los pocos automatizadores que puede actuar como cliente MCP; la mayoría de iPaaS ejecutan sus propios servidores pero no consumen los de terceros. La segunda: invertir la arquitectura y que el agente viva en WhatsApp, con tus herramientas conectadas.
El ángulo MCP y las herramientas de Engage
Esa segunda arquitectura es la de 008 Engage: agentes de texto sobre el ecosistema de Meta, sin webhook que operar. Cada agente tiene prompt, modelo, memoria y un número de pasos de razonamiento por turno configurable; un playground con streaming muestra qué herramienta invoca en cada respuesta, antes de publicar.
Lo interesante para un dev son las herramientas, porque hay tres formas de conectarle lo tuyo. Uno: herramientas HTTP, es decir, tus endpoints —incluida cualquier lógica que ya tengas corriendo en n8n y expuestas como webhook. Dos: plantillas del catálogo que generan herramientas desde especificaciones OpenAPI verificadas: HubSpot, Pipedrive, Zendesk, Salesforce, Calendly y más, más un asistente que lee la documentación de un servicio y construye herramientas a medida. Tres: MCP — Engage actúa como cliente de servidores MCP remotos: le das la URL y la autenticación (bearer o cabecera), descubre las herramientas del servidor y las pone a disposición del agente. Tus sistemas exponen MCP, el agente los usa.
Todo lo que sale del agente pasa por un egress controlado con lista de dominios permitidos, y las credenciales de canal viajan cifradas. El consumo funciona con pago por uso según el modelo de IA que utilices.
Cuál elegir, en una regla
Si el camino se sabe de antemano —notificaciones, sincronizaciones, alertas— el workflow de n8n es la herramienta justa. Si el cliente conversa y la respuesta depende de lo que diga, el agente con herramientas gana. Y si quieres ambas, el patrón híbrido es directo: n8n orquesta lo determinista y expone webhooks; el agente de Engage conversa en WhatsApp y llama a esos webhooks como herramientas, o a tu servidor MCP directamente. Para comparar el salto de capacidad, chatbot clásico vs agente IA lo desglosa turno a turno.
Para montar agentes con herramientas HTTP, catálogo o MCP, crea tu cuenta gratis o pide una demo y lo vemos con tu stack.
Preguntas frecuentes
¿Necesito una app de Meta para usar n8n con WhatsApp?
Sí. El trigger se autentica con el App ID y el App Secret de tu app, y el envío usa un token de acceso más el ID de la cuenta de negocio. Detrás está siempre la Cloud API, con sus requisitos de verificación.
¿Puedo tener varios workflows escuchando mi número?
No en paralelo: una app, un webhook. El patrón habitual es un único workflow de entrada que rutea al resto, o despublicar y republish para alternar test y producción.
¿Por qué el evento de prueba llega pero los mensajes reales no?
Por la suscripción: el evento de prueba del panel de Meta pasa aunque tu app no esté suscrita a la WABA. Revisa subscribed_apps para tu cuenta de negocio y suscribe la app si no aparece.
¿Engage puede conectar mi servidor MCP local?
No. Engage se conecta a servidores MCP remotos por URL, con autenticación bearer o de cabecera. Un servidor local se expone por URL y listo.
¿Qué gana el agente sobre un IF/Switch bien montado?
Flexibilidad de lenguaje: intentos variados, preguntas en cadena y contexto propio se resuelven sin añadir ramas. El workflow no se sustituye: se queda con lo determinista y le delega la conversación.
Te podría interesar

Integrar WhatsApp con Zendesk: guía paso a paso y coste real
Cómo conectar WhatsApp a Zendesk: requisitos de Meta, el flujo oficial en Admin Center, qué plan lo incluye, los tropiezos habituales y el coste total en 2026.

Plantilla de utilidad vs marketing en WhatsApp: cuál usar y cuándo
La diferencia exacta entre plantilla de utilidad y marketing en WhatsApp, las tarifas de Meta vigentes y cómo elegir categoría en diez segundos.

Prompt injection: guía de seguridad para chatbots
Qué es la inyección de prompts, los casos reales que costaron dinero (Tahoe por 1 $, Air Canada) y las cuatro capas de defensa que OWASP recomienda para tu chatbot.
Pon un agente a prueba.
Pide una demo o habla ahora mismo con nuestro agente por WhatsApp.