WhatsApp Webhook: the silent breaking point that brings down the entire operation

What arrives via the webhook

It’s not just messages. The webhook delivers various types of events, each serving a different purpose in the operation:

• Received messages — text, audio, image, video, document, location, contact, and button or list responses.
• Sent message status — sent, delivered, read, and failure, with failure reason when applicable.
• Template events — approval, rejection, and status changes of message templates.
• Number quality and tier — when quality rating changes or sending tier goes up or down.
• Account events — changes in the business account, number, and permissions.

The first three are felt daily by the operation. The last two prevent surprises: companies that don’t listen to quality events only discover the number worsened when sending stops.

The fields that need to be enabled

This is the most common silent error in the entire official API. The webhook subscription has individual fields that must be checked one by one, and an unchecked field doesn’t generate any error: that type of event simply never arrives.

The typical result: the company configures the webhook, tests sending, it works, and discovers days later that customer replies never appeared — because the message field wasn’t checked. Or the opposite: messages arrive, but no one knows if they were read because the status field was left out.

The check that solves this is simple and must be done after any configuration change: enter the webhook subscription, verify that the message and status fields are checked, and send a test message from a personal cell phone to the company number, confirming it appears in the system within seconds.

The subscription exists in two different places

Another point that breaks integrations: webhook configuration doesn’t live in just one place. There’s configuration at the app level, where the callback URL and verification token reside, and there’s the subscription per business account, which determines from which accounts that app receives events.

One configuration without the other produces exactly the most frustrating symptom possible: nothing arrives and no error appears. The URL is correct, the token is correct, the fields are checked — and silence continues because that specific business account was never subscribed.

When a new number is connected, or when the company starts using a different business account, that subscription must be redone. It’s the number one cause of "it worked and then stopped" after reconnecting a number.

What the webhook address needs to have

• Be public and accessible via the internet, with a valid certificate. Internal addresses or expired certificates are rejected.
• Respond quickly. Meta expects confirmation within seconds. Servers that process everything before responding receive retries and duplicate messages.
• Validate the security signature sent with each request to ensure the event really came from Meta and not someone who discovered your URL.
• Handle bursts. Large sends generate many status events in a short time.
• Be stable. Repeated failures can cause Meta to suspend event sending to that address.

The quick response detail is the leading cause of message duplication in homegrown integrations: the correct approach is to confirm receipt immediately and process afterward in the background.

The webhook is tied to the server address

This point deserves emphasis because it silently breaks entire operations: if you change servers, hosting providers, or public address, the webhook points to a place that no longer exists — and messages simply stop arriving, with no warning or visible error on the dashboard.

Sending continues working normally, making diagnosis harder: the team can send messages, customers receive them, and no one understands why replies disappeared. It’s one of the failures that takes the longest to identify.

The remedy is to include webhook reconfiguration in any infrastructure change procedure and perform end-to-end testing immediately afterward — send a message from outside and confirm it appears.

Delivery status: what each means

Status events allow measuring the operation, and each carries different information:

• Sent — Meta accepted the message. Doesn’t mean it arrived.
• Delivered — arrived on the recipient’s device.
• Read — recipient opened the conversation, if read confirmation is active on their side.
• Failed — not delivered, with a code and description of the reason.

The difference between sent and delivered is the most revealing metric of a campaign. A list with many accepted sends but few deliveries indicates a poor base, nonexistent numbers, or blocking — and persisting is the fastest way to degrade number quality.

Webhook and the 24-hour window

There is a direct link between the webhook and the official API’s most important business rule: the service window. When a customer sends a message, a period opens during which the company can respond freely with a message written at the moment, without a template and without the cost of initiating a conversation. After that period, only an approved template can be used to resume.

The event marking the start of this window is precisely what arrives via the webhook. This means poor configuration not only causes delay: it can make the company lose the entire window. If the customer’s message takes hours to appear in the system or doesn’t appear, the seller responds late or outside the deadline — and then needs a template, with cost and the coldness of a standardized message.

In practice, this is the most concrete economic argument to take the webhook seriously. Each lost response due to an event that didn’t arrive is simultaneously a lead cooling off and an additional cost to resume the conversation. In high-volume operations, the difference between a healthy webhook and an unstable one shows directly in the monthly cost of company-initiated conversations.

Symptoms and what each means

• Sending works, reception doesn’t — message fields disabled or business account not subscribed.
• It worked and stopped after reconnecting the number — business account subscription needs to be redone.
• Messages arrive duplicated — server delays confirming receipt, causing retries.
• Messages disappear during peak hours — server can’t handle burst of events.
• Everything stopped after changing servers — old URL in webhook.
• Status never updates — status field not subscribed.

Why almost no one should do this alone

Technically, any company can receive the webhook on its own server. In practice, this means maintaining a service available twenty-four hours a day, handling bursts, validating signatures, avoiding duplicates, storing history, dealing with number reconnections, and redoing configuration every time infrastructure changes.

It’s continuous infrastructure work, not a project with an end. And the cost of errors is high in a specific way: the error doesn’t appear as a failure, it appears as silence — a customer replied and no one saw it.

That’s why most companies use a system that already handles this and delivers the part that matters: the conversation appearing on the seller’s screen, history stored, each message’s status visible, and a report showing delivery, read, and response without anyone needing to check logs.

The webhook does not store history — and that matters

A common misconception makes companies believe that because they use the official API, their conversations are stored somewhere at Meta, ready to be consulted later. They are not. The official API delivers real-time events and does not function as a conversation archive: what isn’t stored by the receiver simply doesn’t exist afterward.

The consequences appear in three very concrete moments. First, when an old customer returns and no one can see what was agreed six months ago. Second, when a seller leaves the company and their conversation needs to be taken over by someone else. Third, when a dispute arises about what was promised, and the company has no record.

That’s why the question about where history is stored should come before the price question when choosing any provider. A system that stores all conversations, allows client search, and exports data on demand turns the webhook into the company’s memory. Without this, each received message is a passing event — seen by a person, at a moment, then lost.

How to test if everything is working

A five-minute checklist that should be redone after any change:

• send a message from a personal cell phone to the company number and confirm it appears in the system within seconds;
• reply via the system and confirm the status changes from sent to delivered and then to read;
• send an image and an audio, because media types sometimes fail separately;
• test a button or interactive list if you use this feature;
• check if a sent template registers status correctly.

Doing this test whenever a number is connected, reconnected, or migrated prevents discovering days later that the operation went without receiving anything.

Where to start

If you already operate: do the end-to-end test today, check if message and status fields are subscribed, verify the business account is in the app’s subscription list, and note somewhere that server changes require webhook reconfiguration. If you’re starting now: choose a system that handles this layer, and use the time saved to focus on what really generates revenue — response speed, lead distribution, and follow-up. A well-configured webhook is invisible; a poorly configured one is silence — and silence on this channel is lost sales without anyone noticing.