Your order system sent a shipping update on WhatsApp. Did it arrive, did the customer read it, and did they reply "wrong address"? On the WhatsApp Cloud API, those answers come back to you as webhook events, and WappBlaster forwards them to your endpoint as signed calls with retries. Developers who treat webhooks as an afterthought end up with duplicate tickets, missing statuses and a support team that cannot see what the customer saw.
Cloud API webhook families: statuses and inbound messages
| Event | What it tells you | Typical action in your system |
|---|---|---|
| Sent | The platform accepted the message | Store the message ID against your record |
| Delivered | It reached the handset | Stamp delivery time; stop any SMS fallback timer |
| Read | The customer opened it (if read receipts are on) | Mark the notice as seen |
| Failed | It did not go through, with a reason code | Flag the record; choose another channel |
| Inbound message or button tap | The customer wrote or tapped something | Create or update a ticket, route to an agent or bot |
Template status changes, such as approval or rejection, matter to whoever manages templates, but most order or CRM integrations can ignore them. WappBlaster's own events add opted-out and button-clicked as separate types, which saves you parsing message text for "STOP".
Carrying your own ID through a Cloud API webhook round trip
When you send through the API, include your own reference, such as an order number or ticket ID. It comes back with every status event for that message. Without it, you store Meta's message ID, keep a mapping table, and look it up on every event, which is one more table to keep consistent under load. With it, a "failed" event for order 48213 updates order 48213, and nothing else needs looking up.
Acknowledge each Cloud API webhook first, do the work afterwards
A webhook sender waits only so long for your response. If your handler calls the CRM, writes three tables and sends an email before returning, a slow moment on any of those causes a timeout, and the sender retries. Now the same event is being processed twice. The safe pattern:
- Verify the signature.
- Write the raw payload to a queue or a simple table.
- Return a 200 response straight away.
- Let a worker read the queue and apply business logic at its own pace.
Keep inbound messages and statuses in separate queues. A burst of delivery receipts after a bulk send should never delay a customer's reply reaching an agent.
Duplicate and out-of-order WhatsApp API webhooks
Retries mean any event can arrive more than once, and network timing means a read event can land before its delivered event. Handle both explicitly:
- Deduplicate on message ID plus status. If you have already recorded "delivered" for that message, ignore the repeat.
- Never downgrade a status. If a message is marked read, a late delivered event should not move it back.
- Store timestamps from the payload, not your server's receive time, so reports reflect what happened on the customer's phone.
Confirming a WhatsApp Cloud API webhook is genuine
Anyone who discovers your endpoint URL can post to it. Each WappBlaster webhook carries a signature you can verify; check it against the raw request body and reject anything that does not match. Do this before parsing JSON, since parsing and re-serialising can change the bytes. Keep any signing secret out of source control. API keys are scoped and rotatable, so a key can be replaced the day a developer with access leaves. Endpoint setup and event formats are covered on the developer webhooks and REST API page.
When you do not need WhatsApp Cloud API webhooks at all
If you only run marketing campaigns and look at the results in a dashboard, the built-in reports already show delivered, read, replied, clicked and opted-out per template, along with Meta's failure reasons. Building and hosting an endpoint adds maintenance for no gain. Webhooks earn their keep when statuses must live in your own database, or when an event should trigger something: a ticket, a CRM update, an AI model you run yourself. Teams without a backend developer can still react to events through a workflow tool; the n8n integration is one self-hostable option. For the wider platform picture, see the complete WhatsApp Business API guide. Webhooks are part of WappBlaster's flat ₹7999 annual plan ($200 outside India); you pay Meta's per-message charge at cost for what you send, and receiving events adds nothing.