Prod: n8n WhatsApp Trigger Not Working (Workflow Published)
Describe the problem/error/question
The production n8n WhatsApp Trigger stopped working today (21 April 2026). The workflow was published, but when a user sent a message, the trigger did not fire.
As a workaround, unpublishing and then republishing the production workflow made the WhatsApp Trigger work again. However, needing to unpublish/republish to restore the trigger is not ideal.
Does anyone know why this happens, or what could be causing the trigger to stop firing?
What is the error message (if any)?
Please share your workflow
Share the output returned by the last node
No output was returned because the node was not being triggered when a user sent a message.
@damjeff the webhook registration goes stale on Meta’s side, republishing just forces a re-register. set up a watchdog workflow that re-activates your whatsapp workflow on a schedule so the webhook stays fresh
swap YOUR_WORKFLOW_ID for the actual id of your whatsapp workflow, set up an n8n API key under Settings → API and use that as the header auth credential with header name X-N8N-API-KEY.
@damjeff this is a known issue — the WhatsApp Cloud API webhook registration goes stale on Meta’s side. As @achamm mentioned, a watchdog workflow is the right fix. Here’s what I run in production:
The watchdog pattern:
A separate workflow on a cron schedule (I use every 6 hours) that calls n8n’s own API to deactivate then re-activate your WhatsApp workflow. The two endpoints you need:
POST /rest/workflows/{id}/deactivate
POST /rest/workflows/{id}/activate
The activate call requires {“versionId”: “…”} in the body — get the current versionId from GET /api/v1/workflows/{id}.
Set up a Header Auth credential with your n8n API key (Settings > API > Add API Key) using header name X-N8N-API-KEY.
Why this works: deactivate + activate forces n8n to re-register the webhook with Meta, which is exactly what unpublishing/republishing does manually. Running it on a schedule means the webhook never stays stale long enough to miss messages.
Bonus — detect it before your users notice:
I also run a monitoring workflow on a 30-min cron that queries GET /rest/executions?status=error&limit=10, filters for my WhatsApp workflow ID, and sends me a notification if there are errors within the last 35 minutes (the overlap avoids re-alerting). This way I know about problems before customers complain.
Been running WhatsApp bots for local businesses in production for months — this pattern has been rock solid.
Hola. Probé tu sugerencia.
Añadí el ID y la clave API.
Sin embargo, cuando ejecuto el nodo, recibo el error que se muestra en la captura de pantalla.
¿Tienes alguna idea de cómo resolverlo?
Separa dos verificaciones aquí: si la propia API de n8n puede leer ese workflow, y si el webhook de WhatsApp de Meta está registrado después de la activación.
Comienza con un GET simple a tu API de n8n para ese ID de workflow. Si devuelve 401 o 403, el problema suele ser autenticación de API/URL base para esa instancia. Si devuelve 404, probablemente el ID no sea el workflow de producción. Si se agota el tiempo o devuelve 5xx, verifica la URL de instancia pública/proxy inverso antes de tocar el nodo de WhatsApp.
Una vez que ese GET devuelva el JSON del workflow, ejecuta las llamadas de desactivación/activación manualmente una vez y luego conviértelas en el watchdog. El detalle útil más pequeño para publicar aquí es el estado HTTP más el texto de error del nodo HTTP que falla.
estoy enfrentando el mismo problema ¿obtuviste alguna solución para esto? si es así por favor cuéntame sobre ello
