I am trying to set up a WhatsApp AI Chatbot using the WhatsApp Trigger and Send Message nodes. I have successfully configured the WhatsApp Business Account ID, Client ID, Client Secret, and Access Token. However, when I try to save the Webhook Callback URL (both Production and Test URLs using POST/GET) in the Meta Developer Console, Meta refuses to validate it and says it is not validated. Because the Webhook isn’t validating, incoming messages do not trigger my n8n workflow. I can only successfully send messages manually using the “Send Message” test button inside the Meta Business Suite dashboard.
**n8n version:** 2.29.5 -
Before clicking Verify, publish the workflow if you are using the production URL or use the test URL, make it listen, and click Verify
Either way, you will need a respond node to return the token to Meta after the listening, so it won’t work the first time; you will just get the token into the datastream and then configure your respond to webhook node with that.
Don’t use the Test URL for permanent Meta configuration, it only works while actively listening. Use the Production URL once your workflow is published and active.
The screenshot shows you’re using the Production URL but the workflow may not be active yet, that’s almost certainly the issue.
Hi @Harsh_Deswal Welcome!
WhatsApp only allows one webhook per app, so each time you paste the Test URL and then the Production URL, the newer one overwrites the previous registration. Meta’s Verify only passes against the single URL that is currently registered and reachable, so switching between the two is what keeps leaving it unvalidated. Register just one URL and don’t alternate while you validate.
You don’t paste the Callback URL into Meta and press Verify yourself with the WhatsApp Trigger node, n8n registers the webhook and answers Meta’s verification handshake for you. Doing it by hand is what keeps coming back as not validated. The reason sending works but the trigger doesn’t is the credential type: “Send Message” runs on the API key credential (Access Token + Business Account ID), while the trigger needs an OAuth2 credential (Client ID is your App ID, Client Secret is your App Secret) to perform that verification. Open the WhatsApp Trigger node, set it to an OAuth2 credential built from your App ID and App Secret, and let n8n do the handshake with Meta instead of the manual Verify.
I think @Harsh_Deswal the test number is the problem here, it often won’t push incoming messages to the trigger until you open the messaging window from your side. Send a WhatsApp message from your own personal number to the test number first, then let n8n reply, and Meta will start forwarding the incoming messages to your workflow. If it still doesn’t come through on the sandbox test number, add and verify your own business phone number, the temporary test number is unreliable for inbound delivery.
See this:
Same issue I ran into a few weeks back, so I get the frustration here.
The core thing that’s actually happening: when you paste the callback URL into Meta yourself and hit Verify, you’re doing the handshake manually. But the WhatsApp Trigger node in n8n is supposed to handle that verification on its own, it registers the webhook and responds to Meta’s challenge automatically. So the manual verify attempt is basically fighting against what n8n is already trying to do behind the scenes.
The bigger thing to check is your credentials. “Send Message” works because it just needs the API key type credential, Access Token plus Business Account ID. But the Trigger node needs an OAuth2 credential built from your App ID (that’s your Client ID) and App Secret (Client Secret). If the Trigger is still sitting on the wrong credential type, that’s almost certainly why the handshake keeps failing even though sending messages works fine.
Also worth double checking, only one webhook URL can be registered per app at a time. If you’ve been switching between Test and Production URLs while trying to validate, the last one pasted overwrites the previous registration, so bouncing between them keeps resetting the state. Pick one URL, make sure the workflow is published and active if it’s the Production URL, and don’t touch it while validating.
Once the credential type is fixed and only one URL is registered, try the verify step again. That combination is usually what fixes it.
