This is one of the more frustrating setups in the n8n ecosystem. Not because the integration is bad, but because every symptom looks identical: the Meta dashboard shows your webhook verified, your WABA subscription confirmed, and your node sitting there with a green check — but real messages from real phones never trigger anything. The n8n community thread that prompted this post had no error text at all. Just silence.
Here's where it actually breaks, in the order I'd check.
The test URL and the production URL are different
This one catches almost everyone the first time. When you open the WhatsApp Trigger node in the n8n editor and click "Listen for test event," n8n exposes a test webhook URL. When you activate the workflow, n8n registers a separate production URL. They're different addresses.
Meta only allows one webhook URL to be registered per App ID. So if you verified the test URL while the editor was open — which is the natural order to do it — and then closed the editor without activating the workflow, you've left Meta pointing at a URL that's no longer listening. The production URL was never registered. Messages arrive at Meta, pass verification against the test URL, and go nowhere because that URL isn't active.
Meta's test button sends a one-off payload directly to whatever URL is currently registered. It fires even if your real subscription is broken, which is why it "works" and real messages don't.
The fix: activate the workflow first, then go to Meta and register (or re-register) the webhook URL. The URL you copy from an activated workflow is the production URL. That's the one Meta should have.
If you need to test while a production workflow is running, you'll need to temporarily deactivate it — or use a separate n8n instance for testing. There's no way around the one-URL-per-App constraint; it's Meta's architecture, not n8n's.
Your Meta app has to own the WABA
Meta distinguishes between apps that are shared with a WhatsApp Business Account and apps that own it. Apps shared with your WABA can't receive webhook notifications — they go through verification fine, and the subscription shows active, but events are never delivered.
To check: in the Meta Business Suite, look at your WABA's app connection. The app handling your webhooks needs to be under your business as an owned app, not as a partner-shared asset. If a previous developer or integration set up the connection, this is the first thing worth verifying — it's a clean setup that delivers nothing, which makes it hard to diagnose by instinct.
The phone number also matters here. A production phone number still attached to a different Meta app's WABA won't deliver events to your app, even after your webhook verifies successfully. The number and the app need to be matched under the same WABA.
Webhook verification and field subscription are two separate steps
Verifying the webhook URL just proves you control the endpoint. It doesn't tell Meta what to send you. After verification, you have to go into the Meta App Dashboard — WhatsApp → Configuration → Webhook Fields — and explicitly subscribe to messages.
This step gets skipped because the verification handshake feels like the finish line. It's not. A verified webhook with no field subscriptions is a connected pipe with the valve shut. Meta has your URL, it's verified, and it'll never send anything until you tell it what events to forward.
While you're there: confirm that the subscription shows "Subscribed" and not just listed. Some integrations get stuck in a pending state after the verification handshake if the n8n response was slow or the workflow wasn't active yet.
Self-hosted n8n needs WEBHOOK_URL set
If you're running n8n on your own infrastructure, the WEBHOOK_URL environment variable has to point to your instance's public HTTPS address. Without it, n8n falls back to localhost when it registers the webhook with Meta — which means Meta sends a verification request to an address it can't reach, the handshake never completes, and no events come through.
This is less common on n8n Cloud (where the URL is handled automatically), but it's the single most common failure on self-hosted setups. Set WEBHOOK_URL=https://your-actual-domain.com and restart the instance. Then re-register the webhook in Meta so the correct URL gets recorded.
Where to start when everything looks right
In order: first confirm which URL Meta has registered (test or production), then check app ownership vs. shared access, then verify that the messages field is actually subscribed in the Webhook Fields section, then check WEBHOOK_URL if you're self-hosted.
None of these produce visible errors on their own. The Meta dashboard reports success at each step because each individual step does succeed — verification succeeds, subscription records — just in a configuration that routes events to nowhere.
We've set up WhatsApp automation for several clients, mostly for intake flows and support routing — the kind of n8n workflow work where a misrouted message costs a real lead. If you're stuck and want a second set of eyes, reach out. Sometimes the issue is visible in thirty seconds once you know where to look.
— Cole
Sources
- n8n WhatsApp Trigger node documentation — n8n docs, 2026
- WhatsApp trigger failures thread — n8n Community (Maven_Simon), 2026; the discussion that prompted this post
- WhatsApp Business Cloud "On messages" trigger never receives events — n8n Community, 2026
- WhatsApp Cloud API messages not reaching n8n webhook — n8n Community, 2026