También apliqué la configuración de proxy inverso de la documentación, ya que un túnel es efectivamente un proxy:
N8N_WEBHOOK_URL=https://[my-tunnel].trycloudflare.com/
N8N_PROXY_HOPS=1 Confirmé que el diagnóstico de Adam13y era correcto: probé la URL de ngrok en un navegador incógnito nuevo (uno que nunca la había visitado) y confirmé que el nivel gratuito de ngrok estaba sirviendo su página intersticial “estás a punto de visitar” a llamadas no reconocidas — lo que explicaría el genérico “Invalid parameter” sin un campo nombrado, ya que Meta nunca habría llegado a la respuesta real de n8n.
Cambié proveedores de túnel para descartar esto completamente: pasé de ngrok a Cloudflare Tunnel (cloudflared tunnel --url http://localhost:5678), que no tiene intersticial. Confirmé conexión saludable, sin página de advertencia.
What is the error message (if any)?
Estado actual, después de todo lo anterior:
El flujo de trabajo se publica correctamente, sin errores
El registro de “Check test webhooks” propio de Meta confirma que está recibiendo mis mensajes de prueba correctamente (campo: messages, carga correcta) cada vez que envío uno
Limpié y volví a registrar la suscripción del webhook desde cero (vía Remove Subscription + republish) para descartar estado obsoleto
A pesar de todo esto: nada aparece nunca en la pestaña Executions de n8n — no una ejecución fallida, no una errónea, genuinamente cero actividad registrada
Así que en este punto: Meta confirma entrega de su lado, el túnel no tiene un problema de bloqueo conocido, los encabezados de proxy están configurados según la documentación, y el flujo de trabajo está activamente publicado y escuchando, pero nada llega al lado de n8n en absoluto.
He descartado todo lo que se puede verificar desde fuera de la instancia en este punto (corrección de URL, salud del túnel, configuración de proxy, estado de suscripción). Si esto te suena familiar a alguien, o si hay una forma de obtener más visibilidad en lo que sucede (o no sucede) internamente cuando n8n recibe un webhook de WhatsApp, realmente apreciaría una indicación.
Please share your workflow
(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
URL de prueba:.../webhook-test/... (Solo activa cuando el flujo de trabajo está abierto y has hecho clic en “Listen for event”)
URL de producción:.../webhook/... (Solo activa cuando el flujo de trabajo está Publicado)
Haz esto
Abre tu nodo Webhook.
Cambia el toggle de URL de prueba a URL de producción.
Copia esa URL exacta.
Ve al Meta Developer Portal y asegúrate de que la URL de Webhook configurada ahí sea la de Producción (sin la cadena -test).
Crucial: Si estás utilizando la URL de producción, no verás la ejecución en tiempo real en el editor. Debes revisar la pestaña Executions en la barra lateral izquierda.
Si N8N_WEBHOOK_URL está configurada incorrectamente en el entorno Docker, n8n puede recibir la solicitud pero no coincidir con un flujo de trabajo porque cree que la solicitud proviene de un dominio no autorizado.
Verifica tu docker-compose.yml o comando Docker run. Asegúrate de que la variable sea exactamente:
(Nota: Asegúrate de que no hay una barra diagonal al final si estás añadiendo rutas en el portal de Meta, o asegúrate de que coincide exactamente. Algunas versiones de n8n son sensibles a la barra diagonal al final en esta variable de entorno).
Ya que nada está llegando a la pestaña Executions, la solicitud está siendo rechazada a nivel del servidor HTTP. Necesitas ver los registros sin procesar del contenedor Docker.
Ejecuta este comando en tu terminal mientras envías un mensaje de prueba desde WhatsApp:
docker logs -f [your_n8n_container_name]
Qué buscar:
404 Not Found: Significa que la URL a la que Meta está accediendo no coincide con ningún webhook activo en n8n. (Verifica Producción vs Prueba).
403 Forbidden: Significa que N8N_WEBHOOK_URL o la configuración de proxy están causando un desajuste de seguridad.
Sin entrada de registro en absoluto: Si no ves nada en los registros cuando Meta dice “Sent”, la solicitud todavía está siendo bloqueada por el túnel o una regla del Firewall de Windows antes de que llegue al motor Docker.
Ya que estás en Windows, Docker se ejecuta en una VM (WSL2). A veces el túnel se asigna a localhost:5678 en Windows, pero el contenedor Docker espera tráfico en su puente interno.
La prueba: Intenta acceder manualmente a tu URL de webhook a través de un navegador o Postman usando una solicitud GET.
Si obtienes {"message":"Workflow not found"} o {"message":"Webhook not found"}, n8n está recibiendo la solicitud. El problema es la carga útil específica de Meta o el registro.
Si obtienes un Timeout o 502/504, el túnel no está llegando al contenedor Docker.
Hola @Rasheed_Alia
Que un evento aparezca solo en “Check test webhooks” significa que Meta construyó el payload, pero no que lo haya enviado a ti. Los mensajes reales van solo al webhook de la aplicación a la que tu WABA está realmente suscrito, y desde el cambio de interfaz de Meta a finales de 2025 esa suscripción a menudo nunca se crea, así que los eventos quedan contra una aplicación del sistema y tu endpoint nunca se llama. Eso coincide exactamente con lo que tienes: la publicación tiene éxito, así que Meta llegó a n8n y obtuvo el challenge correcto de vuelta, y nada llega después.
Abre el Graph API Explorer, establece el método en GET y consulta tu ID de WABA (WhatsApp > API Setup):
<WABA_ID>/subscribed_apps
Si la respuesta está vacía, o el nombre es algo como “WA DevX Webhook Events 1P App” en lugar de tu propia aplicación, cambia el método a POST y envía la misma ruta para suscribir tu aplicación, luego GET nuevamente y confirma que el nombre de tu aplicación está listado. Republica el flujo de trabajo después de eso y envía un mensaje.
Ve esto: