Meta Tech Provider

WhatsApp webhooks: routing messages straight to your server

A WhatsApp webhook is an HTTPS endpoint you nominate, and Meta posts events to it: incoming messages, delivery statuses, quality changes and account updates. On a Coexistence number the destination can be set to your own server, so conversations never pass through a provider at all.

  • Meta posts events straight to your URL
  • Your endpoint, not a provider's platform
  • One override per WhatsApp Business Account
Start Free Trial

Nothing charged for 7 days. Cancel anytime.

No message storageBusiness App + Cloud APIMCP for Claude and ChatGPTLive in 2 minutes
1 URL

What the whole integration is: one HTTPS destination per account.

2 fields

messages and smb_message_echoes, the message path events routed to you.

hub.challenge

The value Meta sends in its GET handshake that your endpoint must echo.

What does Meta actually send to a webhook?

Events, in categories, and the distinction between them decides your architecture.

The message path carries what customers send and, on a Coexistence number, echoes of what your team sends from the WhatsApp Business app. Those are the fields messages and smb_message_echoes, and they are the ones that contain conversation content.

The operational path carries everything else: account_update when a connection state changes, phone_number_quality_update when quality or throughput moves, account_alerts, account_review_update, business_capability_update and phone_number_name_update. These contain no conversation content and are what monitoring is built from.

A provider that puts itself in the message path receives the first group. One that does not, does not.

How does Meta verify an endpoint?

With a GET request before it will deliver anything, and failing this is the most common reason a setup that looks finished never receives a message.

Meta calls your URL with hub.mode set to subscribe, your hub.verify_token, and a hub.challenge value. Your endpoint has to return that challenge as the raw response body, not wrapped in JSON and not with anything added. If it does not, Meta never begins delivering, and nothing in any dashboard will say so.

The endpoint must also be HTTPS. An endpoint that returns a silent 404, or one behind an authentication layer that rejects Meta, looks identical to a working setup right up until the first message never arrives.

Can the destination point at your own server?

Yes, and this is the part that differs between providers.

Meta lets an app override where a given WhatsApp Business Account delivers its webhooks. We set that override to your URL, which moves the message path events from our callback to yours. We keep the operational events, because the dashboard and the alerting are made of them.

The consequence is architectural rather than a policy we publish. Conversation content has nowhere to be stored on our side, because it is never delivered to us. An account with no override set falls back to our default callback, where the handler drops those events without persisting them.

What happens to the destination when a number reconnects?

It is removed, which is the failure almost nobody plans for.

The destination is not a property of the phone number. It is an override on our app's subscription to the WhatsApp Business Account. When a connection is removed, by Meta's fourteen day inactivity rule or otherwise, the app is uninstalled from that account and the override goes with it.

Reconnecting restores sending and restores monitoring. It does not restore delivery to your server, and nothing reports an error, so the first sign is a customer saying nobody replied. We reapply the override on every reconnection, because this happened to a real number that reconnected cleanly and went silent.

Common mistakes

  • Returning JSON from the verification GET. Meta wants the raw hub.challenge value and nothing else.
  • Using a temporary or test URL. Meta keeps delivering to it after the tool that generated it stops listening.
  • Assuming the destination survives a reconnection. It lives on an app subscription and is uninstalled with it.
  • Putting the endpoint behind authentication that rejects Meta's request.
Doing this with EasyCoexistence

EasyCoexistence sets the webhook override to your endpoint, validates it before the call, and reapplies it automatically after any reconnection. US$ 9 per number per month, first 7 days free.

Frequently asked questions

Do my messages pass through EasyCoexistence?

No. The override sends message path events from Meta straight to your endpoint. Events for an account with no override fall back to our callback and are dropped without persisting.

Can I change the destination later?

Yes, at any time, from the dashboard or through the MCP connector. Passing null resets it back to our default.

What if my server is down when Meta delivers?

Meta retries for a period and then stops. Messages still arrive in the WhatsApp Business app on the phone, so the business loses nothing even when the integration does.

Is one webhook enough for several numbers?

Yes. Point every number at the same endpoint and branch on the receiving phone number id in the payload.

Keep reading

Ready to get started?

Set up WhatsApp Coexistence in minutes, not months. The app keeps working on the phone.

Start Free TrialNothing charged for 7 days. Cancel anytime.

Verified on

WhatsApp Webhooks Explained