WhatsApp Trigger failing on Self-Hosted n8n. Where to set Meta Verify Token?

[ldaniel-jmz]

I’m encountering issues getting the Meta webhook verification to work for the WhatsApp Trigger node on my self-hosted setup, and I’m hoping for some guidance on the correct configuration, particularly regarding the Meta Verify Token.

The Problem & Observations:

1. Active Workflow Functions Correctly: When the workflow is activated, it successfully receives and processes incoming WhatsApp messages sent via the WEBHOOK_URL. This confirms basic credentials (for sending), Traefik routing for POSTs, and DNS are okay.

2. “Test Step” Fails with 404: Clicking “Test step” on the WhatsApp Trigger node consistently results in: (#2200) Callback verification failed... HTTP Status Code = 404; HTTP Message = Not Found. This seems consistent with the queue mode testing issue reported in GitHub Issue #13361, likely using the wrong base URL for the test callback.
   

   

3. Primary Issue: Meta Verification Fails: The main blocker is that I cannot complete the initial webhook verification within the Meta App Dashboard using the production webhook URL (https://webhook.mydomain.com/webhook/...). It simply fails without a specific error message from Meta.

4. Missing Verify Token Field in UI: I cannot find a field within either the WhatsApp API or WhatsApp OAuth API credential types in the n8n UI to input the “Verify Token” required by Meta.

5. WEBHOOK_VERIFY_TOKEN Env Var Attempted: Following advice from other forum posts, I have added the WEBHOOK_VERIFY_TOKEN=MY_SECRET_TOKEN environment variable (using my actual token) to the environment: sections of my n8n_editor, n8n_webhook, and n8n_worker services in the docker-compose.yml file and updated the stack.

6. Verification Still Fails: Even with the WEBHOOK_VERIFY_TOKEN environment variable set, attempting verification in the Meta dashboard still fails.

Core Questions:

1. For n8n v1.88.0 self-hosted in queue mode, what is the correct method for configuring the Meta Verify Token for the WhatsApp Trigger node? Is the WEBHOOK_VERIFY_TOKEN environment variable the intended way?
2. If the environment variable is correct, why might Meta verification still be failing? Any common pitfalls with this setup?

• n8n version: 1.88.0
• Database: PostgreSQL
• n8n EXECUTIONS_PROCESS setting: queue
• Running n8n via: Docker (via Portainer)
• Operating system: Ubuntu 22.04.5 LTS (on VPS via Peramix)

[tridi]

How about your Meta Apps config?
Token verification is simply adding on Whatsapp Products Config with your webhoook URL that provided on Whatsapp Cloud Trigger

[ldaniel-jmz]

Already set up the URL callback with the n8n production webhook that shows on the WhatsApp trigger node, but don’t know what to put on the Token Verification field (red circle):

[tridi]

you can type anything you want on there and n8n whatsapp cloud webhook will do validation for it

Before that trigger node existed, you had to create your own ‘get’ method to perform the token validation. However, with the WhatsApp Cloud node, you only need to set up the webhook and fill in the custom token in those Meta Apps, and then click ‘verify token’.

[ldaniel-jmz]

Hey @tridi

This worked indeed . The thing is that the workflow must be active for the Token Verification to work on the meta app configuration (mine was inactive for testing purposes )

Ran into a looping issue right after, caused by the trigger firing on the "sent" status updates Meta sends under the messages field subscription.

Found the native fix within the trigger node itself, but it has a specific setup:

1. The “Receive Message Status Updates” option isn’t there by default under “Options”. You have to Add Option → Receive Message Status Updates.
2. It initially defaults to “All”. You must click the ‘x’ on “All” to clear the selection, leaving the field empty (Select placeholder visible). This stops it triggering on statuses.

Important UI Tip / Warning:
Do NOT delete the entire “Receive Message Status Updates” option line using the trash can icon (see screenshot below) after clearing the selection. Deleting the line seems to revert it back to receiving all statuses. The option line must remain, just with an empty selection.

Sharing this discovery, especially the setup steps and the UI quirk, in case it helps others. Thanks for getting me past the token verification hurdle!