WhatsApp inbound messages not reaching n8n despite verified webhook + confirmed WABA subscription

Questions
, , ,
1

I’m setting up a WhatsApp Business Cloud integration in n8n Cloud (version visible in Executions panel) and inbound messages never trigger a workflow execution, despite every check passing:

Describe the problem/error/question

Inbound WhatsApp messages don’t trigger any workflow execution, despite the webhook being verified by Meta and the app being confirmed as subscribed to the WABA. Meta’s own real-time webhook test panel confirms it IS sending the message events, but n8n never registers an execution for them — only the original verification GET request ever appears in Executions.
I initially tried the native “WhatsApp Trigger” node, but its “WhatsApp OAuth account” credential consistently fails with “Bad request - please check your parameters” / “Error validating client secret” even with correct Client ID/Secret (matches other reported threads). As a workaround, I switched to a generic Webhook node (GET+POST via “Allow Multiple HTTP Methods”) + a “Respond to Webhook” node returning {{ $json.query[“hub.challenge”] }} for the verification handshake. Verification succeeds and the WABA subscription (POST /{WABA_ID}/subscribed_apps) returns success:true, but real inbound messages still never reach n8n.

What is the error message (if any)?No error is shown — the workflow simply never executes for inbound messages. No new entry appears in Executions after sending a real WhatsApp message, even though Meta’s test panel confirms the event was sent.

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hey @FAOR_Beauty_Skin, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@fahmiiireza, @tridi, @LogeshwariV - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @FAOR_Beauty_Skin Welcome!
A verification GET that lands and nothing after it is the signature of the test URL. n8n registers the test URL only while the canvas is listening and drops it after 120 seconds, so Meta’s handshake falls inside that window and every later message hits a path n8n no longer serves. The production URL only exists once the workflow is published.
Publish the workflow, then set the Meta callback to the production path /webhook/1490d3bd-a1f9-476b-9e03-c14c2ab22743 rather than the /webhook-test/ form, and re-verify. Prove it from your side before going back to Meta:

curl -X POST https://<your-instance>.app.n8n.cloud/webhook/1490d3bd-a1f9-476b-9e03-c14c2ab22743 -H "Content-Type: application/json" -d '{"ping":true}'

If that call does create an execution and real messages still never arrive, the URL is fine and the gap is the messages field subscription under Webhook fields in the app’s WhatsApp configuration, which is a separate thing from the subscribed_apps call you already ran against the WABA.

4

Your Webhook node is registered for GET only, so Meta’s verification succeeds and every actual message POST gets a 404. That’s why delivery looks confirmed on Meta’s side and nothing ever shows up in your Executions.

It’s visible in the JSON you posted — the Webhook node has no httpMethod:

"parameters": {
  "path": "1490d3bd-a1f9-476b-9e03-c14c2ab22743",
  "responseMode": "responseNode",
  "options": {}
}

n8n strips option parameters left at their default when it saves, and the default for httpMethod is GET. You mention you switched to GET+POST via “Allow Multiple HTTP Methods” — but that setting isn’t in the export, and I checked that it would be if it were on. Exporting the same workflow with it enabled gives you:

"parameters": {
  "multipleMethods": true,
  "httpMethod": ["GET", "POST"],
  "path": "wa-multi",
  "responseMode": "responseNode",
  "options": {}
}

So at the moment you took that export, the node was GET-only. Either the change didn’t save, or the export predates it. Worth reopening the node to check — and if the UI does show it enabled, re-save and re-export, because then the setting isn’t persisting and that’s a separate bug worth reporting.

I reproduced it on 2.32.7 rather than guessing. Two workflows, identical except for that one setting, both active:

webhook_entity
reprowh01  wa-default  GET     <- your config: no httpMethod
reprowh02  wa-multi    GET     <- multipleMethods: true
reprowh02  wa-multi    POST

And live:

GET  /webhook/wa-default  ->  200
POST /webhook/wa-default  ->  404   <- where Meta's messages land
GET  /webhook/wa-multi    ->  200
POST /webhook/wa-multi    ->  200

The fix is Allow Multiple HTTP Methods with GET and POST, or two separate webhooks on the same path — one GET for the hub.challenge handshake, one POST for messages. The second is cleaner, because your Respond node returns $json.query["hub.challenge"], which only makes sense on the GET branch. As it stands, if a POST ever did arrive, you’d answer Meta with an empty body.

The native WhatsApp Trigger failing with “Error validating client secret” is a separate problem — that one is in the credential, not the routing. Probably worth its own thread once this is unblocked, so the two don’t get tangled.

5

@FAOR_Beauty_Skin

In n8n, there is a massive difference between the Editor and the Production environment.

  • The Problem: When you are testing in the editor (clicking “Execute Workflow”), n8n listens on the Test URL. When you click “Verify” in Meta, Meta is likely using the Production URL.
  • The Symptom: If you have not toggled the switch in the top right of n8n to “Active”, n8n will receive the POST request from Meta, see that no workflow is “listening” for it in production mode, and simply discard it. It will not show up in your execution list.
  • The Fix:
    1. Ensure you are using the Production URL (no /test/ in the path) in the Meta Developer Console.
    2. Activate the workflow (the toggle in the top right must be ON).
    3. Check the “Executions” tab (not the editor) to see if the POSTs are arriving.

Meta has two different places to configure Webhooks, and they behave differently.

  • The Problem: If you configured the Webhook URL under the general “Webhooks” section in the left-hand sidebar of your Meta App, you are telling Meta: “Send me updates about the App (like changes to App settings or User permissions).”
  • The Fix: You must configure the Webhook URL inside the specific WhatsApp product section:
    1. Go to your Meta App Dashboard.
    2. Look at the sidebar under “Products”.
    3. Click “WhatsApp” $\rightarrow$ “Configuration”.
    4. This is where your Webhook URL and Verify Token must be entered. If you put them in the general “Webhooks” tab, you will pass the handshake, but you will never receive WhatsApp messages.

Even if the URL is correct and the handshake is verified, Meta will not send data unless you explicitly ask for it.

  • The Problem: You have verified the connection, but you haven’t subscribed to the content.
  • The Fix:
    1. In the WhatsApp $\rightarrow$ Configuration page (where you put your URL), look for a section called “Webhook fields”.
    2. You must click “Manage”.
    3. Look for the row named messages.
    4. Ensure it is marked as “Subscribed”. If you don’t see “Subscribed” next to messages, Meta will stay silent even if the webhook is “verified.”

While you mentioned you enabled “Allow Multiple HTTP Methods,” double-check the specific configuration of that Webhook node.

  • The Problem: If the node is explicitly set to GET only, it will ignore the POST from Meta.
  • The Fix:
    • Open your Webhook node.
    • Under HTTP Method, ensure it says GET, POST (or you have selected both).
    • Note: Some versions of the node require you to select the method from a dropdown. If you only see one, ensure you aren’t accidentally filtering out POST requests.

Does that help?