Also applied the reverse proxy config from the docs, since a tunnel is effectively a proxy:
N8N_WEBHOOK_URL=https://[my-tunnel].trycloudflare.com/
N8N_PROXY_HOPS=1 Confirmed Adam13y’s diagnosis was correct: tested the ngrok URL in a fresh incognito browser (one that had never visited it before) and confirmed ngrok’s free tier was serving its “you are about to visit” interstitial page to unrecognized callers — which would explain the generic “Invalid parameter” with no field named, since Meta would never have reached n8n’s actual response.
Switched tunnel providers to rule this out entirely: moved from ngrok to Cloudflare Tunnel (cloudflared tunnel --url http://localhost:5678), which doesn’t have an interstitial. Confirmed healthy connection, no warning page.
What is the error message (if any)?
Current state, after all of the above:
Workflow publishes successfully, no errors
Meta’s own “Check test webhooks” log confirms it’s receiving my test messages correctly (field: messages, correct payload) every time I send one
Cleared and re-registered the webhook subscription fresh (via Remove Subscription + republish) to rule out stale state
Despite all of this: nothing ever appears in n8n’s Executions tab — not a failed execution, not an errored one, genuinely zero activity logged
So at this point: Meta confirms delivery on their end, the tunnel has no known blocking issue, proxy headers are configured per the docs, and the workflow is actively published and listening, but nothing is landing on the n8n side at all.
I’ve ruled out everything checkable from outside the instance at this point (URL correctness, tunnel health, proxy config, subscription state). If this rings a bell for anyone, or if there’s a way to get more visibility into what happens (or doesn’t happen) internally when n8n receives a WhatsApp webhook, I’d really appreciate a pointer.
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Test URL:.../webhook-test/... (Only active when the workflow is open and you’ve clicked “Listen for event”)
Production URL:.../webhook/... (Only active when the workflow is Published)
Do this
Open your Webhook node.
Switch the toggle from Test URL to Production URL.
Copy that exact URL.
Go to the Meta Developer Portal and ensure the Webhook URL configured there is the Production one (without the -test string).
Crucial: If you are using the Production URL, you will not see the execution happen in real-time in the editor. You must check the Executions tab in the left sidebar.
If N8N_WEBHOOK_URL is set incorrectly in the Docker environment, n8n may receive the request but fail to match it to a workflow because it thinks the request is coming from an unauthorized domain.
Check your docker-compose.yml or Docker run command. Ensure the variable is exactly:
(Note: Ensure there is no trailing slash if you are appending paths in the Meta portal, or ensure it matches exactly. Some versions of n8n are sensitive to the trailing slash in this env var).
Since nothing is hitting the Executions tab, the request is being rejected at the HTTP server level. You need to see the raw logs of the Docker container.
Run this command in your terminal while sending a test message from WhatsApp:
docker logs -f [your_n8n_container_name]
What to look for:
404 Not Found: Means the URL Meta is hitting doesn’t match any active webhook in n8n. (Check Production vs Test).
403 Forbidden: Means the N8N_WEBHOOK_URL or proxy settings are causing a security mismatch.
No log entry at all: If you see nothing in the logs when Meta says “Sent,” the request is still being blocked by the tunnel or a Windows Firewall rule before it even reaches the Docker engine.
Since you are on Windows, Docker runs in a VM (WSL2). Sometimes the tunnel maps to localhost:5678 on Windows, but the Docker container is expecting traffic on its internal bridge.
The Test: Try to hit your webhook URL manually via a browser or Postman using a GET request.
If you get {"message":"Workflow not found"} or {"message":"Webhook not found"}, n8n is receiving the request. The problem is the Meta-specific payload or registration.
If you get a Timeout or 502/504, the tunnel is not reaching the Docker container.
Hi @Rasheed_Alia
An event showing up in “Check test webhooks” only means Meta built the payload, not that it sent it to you. Real messages go only to the webhook of the app your WABA is actually subscribed to, and since Meta’s UI change in late 2025 that subscription often never gets created, so the events sit against a system app and your endpoint is never called. That matches exactly what you have: publish succeeds, so Meta reached n8n and got the right challenge back, and nothing arrives afterwards.
Open the Graph API Explorer, set the method to GET, and query your WABA ID (WhatsApp > API Setup):
<WABA_ID>/subscribed_apps
If the response is empty, or the name is something like “WA DevX Webhook Events 1P App” rather than your own app, switch the method to POST and send the same path to subscribe your app, then GET again and confirm your app name is listed. Republish the workflow after that and send a message.
See this: