Meta says your webhook is verified. So why do no messages arrive?

Why does the test work and the real message not?

Because they are testing different things. Verifying your webhook confirms Meta can reach your address. Delivery of live messages depends on a separate step: subscribing your app to the specific webhook field that carries messages. An endpoint can be perfectly verified and subscribed to nothing at all.

Meta's documentation puts the two in sequence, and the sequence is easy to stop halfway through:

Once you have created and configured your webhook endpoint (or have set up a test webhook endpoint), use the App Dashboard > WhatsApp > Configuration panel to subscribe to individual webhook fields.

• Webhooks, WhatsApp Business Platform documentation, read 18 August 2026

"Individual webhook fields" is the part that costs people evenings. On that same page Meta lists nineteen of them - account alerts, template status updates, quality scores, payment configuration - and the one that carries a customer writing to you is just one entry in that list:

The messages webhook describes messages sent from a WhatsApp user to a business and the status of messages sent by a business to a WhatsApp user.

• Webhooks, WhatsApp Business Platform documentation, read 18 August 2026

Subscribe to none of them and your setup looks complete from every screen you have been shown.

Is this actually a common way to lose an afternoon?

Common enough that the same symptom shows up repeatedly on the forum of one automation platform alone. From n8n's community in July:

when i send the message from my personal whatsapp number to the test number the n8n flow does not trigger however when i press test button on message workfow in meta webhook page then the workflow triggers - i am unable to find the discrepancy

• a user, Whatsapp trigger is not fired on WA message however it is fired when tested via meta webhook, n8n Community, 23 July 2026, read 18 August 2026

The first answer in that thread points at the subscription:

In Meta for Developers - WhatsApp - Configuration, make sure the messages field is checked under Webhook Fields.

• another user, same thread, 23 July 2026

That thread is still marked unsolved, which is worth knowing before you assume the checklist below is the end of it. But it is unsolved in the sense that the person who asked never came back - not in the sense that nobody worked it out. Two weeks later, someone posted the answer that fits this exact symptom:

In Development mode, Meta only fires webhook events for numbers explicitly added as test recipients. Your personal number isn't one, so Meta accepts and delivers the message but never sends the webhook event. [...] The Meta test button works because it posts directly to your URL and skips the subscription layer entirely.

• another user, same thread, n8n Community, 6 August 2026

That is the sharpest version of the whole problem. The test button and a real message do not travel the same road: one is posted straight at your URL, the other has to clear the subscription layer first. So a green verification proves the road exists, and proves nothing about whether messages are allowed onto it. If your app is still in Development mode, the phone you are testing from has to be on the test-recipient list in API Setup, verified by SMS - otherwise the message arrives on WhatsApp and the webhook never fires.

Subscription is still the most common cause. It is not the only one.

What else sits between a verified endpoint and a delivered message?

The address you gave Meta, and which app is listening. Two failure modes in that category come up repeatedly, and neither produces an error anywhere:

The wrong URL of the pair. Automation tools usually expose two addresses for the same workflow - a test one that only listens while you are watching, and a production one that listens always. Paste the first into Meta and everything works while you sit in the editor and nothing works afterwards:

In n8n, your webhook has two different URLs: one for testing (.../webhook-test/...) and one for production (.../webhook/...). Check which exact URL you pasted into the Meta Developer Console.

• another user, same thread, n8n Community, 23 July 2026, read 18 August 2026

The webhook attached to the wrong product. A Meta app can carry several products, each with its own webhook configuration, and the dashboard will happily let you configure the one you did not mean:

Meta needs to know which part of your app should receive the webhook. [...] There is often a dropdown menu to "Select a product" for the webhook. Ensure you have selected "WhatsApp Business Account" (or similar WhatsApp-related product) from that dropdown.

• a user, WhatsApp Trigger not receiving any messages always bad parameters, n8n Community, 10 August 2026, read 18 August 2026

What order should you check things in?

From the message's point of view, walking the path it takes rather than the screens you happen to remember:

1. Confirm the subscription first, in App Dashboard, WhatsApp, Configuration. If messages is not ticked in Webhook Fields, stop - you have found it, and nothing further down the list matters.
2. Compare the URL in Meta character by character with the production URL from your automation tool. Not the test one, and not one you retyped.
3. Check which product the webhook is configured under in the app, if your app has more than one.
4. Send a real message from a phone that is not yours, and watch the automation's execution log rather than the Meta test button. The test button has already told you everything it can.
5. Look at what your endpoint returns. Meta judges delivery by your HTTP response code, and anything other than 200 puts you into the retry path below.

What happens if your endpoint answers badly?

Meta keeps trying, for a surprisingly long time, and then the retries themselves become a second problem:

If a webhook request to your endpoint receives an HTTP status code other than 200, or if the webhook cannot be delivered for another reason, Meta retries delivery with decreasing frequency until the request succeeds, for up to 7 days.

• Webhooks, WhatsApp Business Platform documentation, read 18 August 2026

Seven days of retries against an endpoint you fixed on day two means a backlog of old customer messages arriving as if they were new. If your automation replies automatically, it will reply to all of them.

There is a second multiplier documented in the same place:

Note that Meta sends retries to all apps that have subscribed to webhooks (and their appropriate fields) for the WhatsApp Business account. These retries can result in duplicate webhook notifications.

• Webhooks, WhatsApp Business Platform documentation, read 18 August 2026

So if an old test app is still subscribed to the same business account alongside your live one, both receive everything - which is one of the ways a single event ends up processed twice.

Why does an image or voice note arrive without the file?

Because a media message carries a reference, not the file, and the reference has a short life of its own. Meta documents three different clocks, and mixing them up produces automations that work in testing and fail on real traffic:

Media IDs returned by the API expire after 30 days. Media IDs in webhooks expire after 7 days.

• Media, WhatsApp Business Platform documentation, read 18 August 2026

and the download address itself is far shorter-lived:

Media URLs expire after 5 minutes, after which you must query the ID again to get a new URL.

• Media, WhatsApp Business Platform documentation, read 18 August 2026

The practical rule that follows: an automation must fetch the file during the run that received the message, not later from a stored address. And the request needs your credentials attached, which is the part people miss because the address looks like an ordinary link:

Include your access token in the request. If you omit your token, the request will fail.

• Media, WhatsApp Business Platform documentation, read 18 August 2026

Why does the platform's own documentation not save you here?

Because the missing step belongs to Meta, and your automation tool documents its own half. The n8n or Make node tells you how to create a trigger and where to paste credentials; the field subscription lives in a different company's dashboard, and neither vendor owns the sentence that would connect them.

This is worth naming because it changes where you look when something breaks. Time spent re-reading the automation tool's documentation is time spent in the half that is already working - the same trap as an editor showing a change that production never received, where the screen you trust is not the screen that decides.

How do you keep it working once it works?

By writing down the three things nobody remembers six months later: which app and which business account the number is attached to, which URL Meta is pointing at, and which fields are subscribed. That note is the entire recovery procedure when someone rebuilds the workflow, rotates a token, or adds a second app for testing.

The failure this prevents is quiet in the worst way. A WhatsApp automation that stops delivering does not error - it simply stops, and the business finds out from a customer who says they wrote last week. Silence is the one failure that generates no alert, so the check has to be something you do, not something you wait for.

When is this worth handing over?

If you own the Meta app, the number is yours, and messages simply never arrive, work the list above yourself. The fix is usually one checkbox, and paying anyone to tick it would be silly.

It becomes a real job when the number sits inside somebody else's business account, when several apps are subscribed to the same account and nobody knows which one is live, when media has to be captured and stored within the five minute window, or when a week of retried messages needs to be processed without auto-replying to customers who have already been dealt with. Untangling that means proving what is subscribed where, and then proving each message arrives exactly once - work with an end state you can check, which is what a fixed-price Fix M is scoped around.

Sources

• Webhooks - WhatsApp Business Platform documentation, read 18 August 2026. Field subscription as a separate step from endpoint configuration, the list of webhook fields including messages, the seven-day retry behaviour, and duplicate notifications across subscribed apps.
• Media - WhatsApp Business Platform documentation, read 18 August 2026. Media ID lifetimes of thirty days from the API and seven days from webhooks, the five-minute media URL expiry, and the access token requirement for downloads.
• Whatsapp trigger is not fired on WA message however it is fired when tested via meta webhook - n8n Community, thread opened 23 July 2026, read 18 August 2026, re-read 25 August 2026. The test button working while real messages do not, the field subscription answer, the test-versus-production URL distinction, and the Development-mode test-recipient explanation posted on 6 August.
• WhatsApp Trigger not receiving any messages always bad parameters - n8n Community, thread opened 10 August 2026, read 18 August 2026. The webhook configured under the wrong product in a Meta app.