[BUG] WhatsApp Trigger — “Bad request - please check your parameters” on startup, never enters listening mode Environment
n8n version: 2.23.3
Installation: npx n8n (Node.js, Windows)
OS: Windows 11
Tunnel: ngrok (ngrok-free.app)
WhatsApp node: WhatsApp Trigger (official n8n node, version 1 latest)
Credential type: WhatsApp OAuth Problem description
When I click “Test this trigger” on the WhatsApp Trigger node, the workflow immediately throws the error “Bad request - please check your parameters” without ever entering listening mode (“Waiting for trigger event…”). The node never registers the webhook. Terminal logs
Bad request - please check your parameters
Bad request - please check your parameters
Database connection timed out
Database connection recovered
Bad request - please check your parameters
Received request for unknown webhook: The requested webhook "26ac6c82-dd08-40c3-a624-5805b663b1ab/webhook" is not registered.
404 The requested webhook "26ac6c82-dd08-40c3-a624-5805b663b1ab/webhook" is not registered.
Bad request - please check your parameters
What I have already tried
Verified credentials: WhatsApp OAuth connection test returns “Connection tested successfully”
Configured webhook URL + Verify Token in Meta Developer Console
Tried clicking “Test this trigger” before clicking “Verify” in Meta
Restarted n8n with npx n8n start
Confirmed ngrok is online and forwarding to localhost:5678
Confirmed n8n also exposes its own ngrok tunnel on the same port (possible conflict?) Suspected cause
I noticed n8n exposes its own ngrok tunnel AND I was running a separate ngrok instance on the same port 5678 simultaneously. Could this conflict cause the “Bad request” and database timeout issues? Question
Is the “Bad request” triggered by n8n trying to register the webhook with Meta and failing? If so, what exactly does n8n send to Meta at that moment, and what could cause Meta to reject it?
Any help appreciated, thank you! French answers will be also appreciated
The “Bad request” error you’re seeing is actually a failed “handshake” between n8n and Meta. When you test the trigger, n8n tells Meta, “Please send my messages to this web address.” Meta immediately tries to call that address to verify it’s real. If Meta doesn’t get the exact right response back instantly, it rejects the connection, and n8n shows you that generic “Bad request” message.
Your logs show that Meta is actually reaching your computer, but n8n is rejecting the call as an “unknown webhook.” This happens because n8n is confused about its own identity. It hasn’t finished registering the webhook yet, so when Meta calls to verify it, n8n doesn’t recognize the request and hangs up on Meta, which causes the registration to fail.
The root cause is that you have two different “tunnels” (n8n’s built-in one and your manual ngrok one) fighting over the same port. It’s like having two different front doors to the same house; the system doesn’t know which one to use. This conflict is not only breaking the WhatsApp connection but is also causing the “database timeout” errors because your network connection is becoming unstable.
To fix this, you need to simplify your setup. Turn off n8n’s built-in tunnel and use only your manual ngrok link. Most importantly, you must explicitly tell n8n exactly what that ngrok address is by setting a WEBHOOK_URL environment variable. This ensures n8n gives Meta the correct address and recognizes the verification call when it arrives.
From what you described and the logs you shared, the problem is not the WhatsApp Trigger node itself but how the webhook and tunnels are set up around it.
The most likely root cause is the double-tunnel setup: you are running your own ngrok on port 5678 while n8n also starts its own tunnel on the same port, so Meta does not have a single, stable HTTPS URL to talk to and the webhook registration fails immediately with “Bad request - please check your parameters”. When you click “Test this trigger”, n8n calls the Meta API to subscribe your app to WhatsApp events using the webhook URL it knows about, but if that URL does not match the one configured in the Meta Developer Portal (or it points to the “other” tunnel), Meta rejects the request and n8n shows the generic Bad request error.
I would suggest these concrete steps:
Stop your separate ngrok process and let n8n manage the tunnel on its own, or do the opposite (use only your own ngrok URL and disable the n8n tunnel) – but never both at the same time.
In the Meta Developer Portal, make sure the webhook is configured under the “WhatsApp Business Account” product and that the callback URL is exactly the HTTPS URL that n8n (or your single ngrok instance) exposes.
Use the Graph API Explorer on phone_number_id/subscribed_apps to confirm that your app is actually subscribed to your phone number; if the response is empty, you need to POST to that endpoint to subscribe it before the trigger can enter “listening mode”.
Once you have a single tunnel, the correct product selected and the app properly subscribed, the WhatsApp Trigger should move from “Bad request” to “Waiting for trigger event” when you test it.
Oh I am so sorry it didn’t work, after entering the command,
Delete the WhatsApp Trigger node from your canvas completely, save the workflow.
Refresh your tab and then add a brand new WhatsApp Trigger node back onto the canvas.
Open the WhatsApp Trigger node.
Ensure your credentials pass the connection test.
Do not click verify in Meta yet.
Click Test step or Listen for test event inside n8n first. The UI should now cleanly spin into a waiting state because there are no network/port collisions.
While n8n is spinning and actively listening, trigger a test message from a real phone number to your WhatsApp Business number, or manually paste n8n’s provided URL/Token into Meta’s dashboard to complete the validation handshake.
@Samuel_Kponzot one thing to double-check: when you run npx n8n start --tunnel, n8n generates a brand new tunnel URL each time. You need to go back to the Meta Developer Portal and update the callback URL there with this new URL - it won’t match your old ngrok address anymore. When n8n starts with the tunnel, look in the terminal output for the tunnel URL (something like https://xxxx.hooks.n8n.cloud/) and paste that into the WhatsApp webhook callback field in Meta, then click Verify and Save. If the URL in Meta still points to your old ngrok address, Meta will keep rejecting the handshake regardless of what n8n is doing.
Welcome to the n8n community @Samuel_Kponzot
please always keep your instance updated to the stable version, 2.23.4, check if the callback URL in Meta is exactly the same as displayed by the WhatsApp Trigger, Verify Token the same in n8n and in Meta, and if the Meta App has the WhatsApp/Webhooks product configured with correct permissions.
according to the documentation, this is an error in the parameters
Open your local n8n panel (http://localhost:5678).
Open your workflow and look at your WhatsApp Trigger node.
Because you set the environment variable, n8n will now dynamically generate a Webhook URL that hopefully starts with your ngrok address instead of localhost.
Copy this new https:// webhook URL and the Verify Token from the node.
Go to your Meta App dashboard, then WhatsApp, then to configuration.
Paste the new ngrok-based webhook URL and the verify token.
Click save and verify, meta will send a test ping, ngrok will forward it, n8n will recognize its own URL, and the verification will hopefully succeed.
@Samuel_Kponzot To be clear: n8n tunnel (–tunnel) can be unreliable on self-hosted local installs, and, as you’ve noted, is not officially supported for production. The ngrok approach is heading in the correct direction, but there’s something else to look at. Meta requires a specific confirmation challenge value in the response to a GET request to the webhook verification URL. If Meta’s verification ping attempts to contact your ngrok URL and n8n is not yet fully up and running at that moment, or if the WEBHOOK_URL env var is not set prior to n8n, Meta’s verification ping will return a bad request.
Additionally, Meta’s webhook URLs may require there not be a trailing slash in certain configurations. If you keep receiving bad requests, try both ways with https://your-ngrok-url.ngrok-free.app/webhook/… as well as with and without the trailing slash.
The “tunnel stays on localhost” part is the key clue. The built-in --tunnel sometimes does not generate the hooks.n8n.cloud URL reliably, and even when it does, Meta needs the publicly reachable HTTPS callback, so the cleaner path is to run your own ngrok and tell n8n about it explicitly, which the reply above lays out.
The piece people miss: starting ngrok is not enough, you have to set WEBHOOK_URL to the ngrok https URL before starting n8n, otherwise n8n keeps building callback URLs on localhost and Meta rejects them as a Bad Request. So: ngrok http 5678, copy the https URL, set WEBHOOK_URL to it, then start n8n, then open the WhatsApp Trigger and the callback it shows you should now be the ngrok URL, and that is the one to paste into the Meta portal.
One catch with free ngrok: the URL changes every restart, so every time you restart you have to update WEBHOOK_URL and re-paste the callback in Meta, which is why this is painful for anything beyond testing. For something a client relies on, moving n8n to a host with a real domain and HTTPS removes the tunnel dance entirely. Are you doing this for testing, or does it need to run continuously? That decides whether ngrok is fine or you want a proper host.
