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.
Bonjour. J’ai essayé votre suggestion.
J’ai ajouté l’ID et la clé API.
Cependant, lors de l’exécution du nœud, j’obtiens l’erreur visible dans la capture d’écran.
Avez-vous une idée de comment résoudre ce problème s’il vous plaît ?
Séparez deux vérifications ici : si l’API propre de n8n peut lire ce workflow, et si le webhook WhatsApp de Meta est enregistré après l’activation.
Commencez par un GET simple sur votre API n8n pour cet ID de workflow. S’il retourne 401 ou 403, le problème vient généralement de l’authentification API/l’URL de base de cette instance. S’il retourne 404, l’ID n’est probablement pas le workflow de production. S’il expire ou donne un 5xx, vérifiez l’URL d’instance publique/reverse proxy avant de toucher au nœud WhatsApp.
Une fois que ce GET retourne le JSON du workflow, exécutez les appels désactiver/activer manuellement une fois, puis transformez-les en watchdog. Le plus petit détail utile à poster ici est le code de statut HTTP plus le texte d’erreur du nœud HTTP défaillant.
