Short answer: WhatsApp’s status webhook reports five values — sent, delivered, read, failed and played. Only read means a human opened the thread. A delivered/read rate built from webhooks is honest arithmetic, but the denominator moves: webhooks retry, deduplicate and expire after 36 hours, and delivered is sometimes skipped entirely.
The five statuses Meta actually defines
Most Indian messaging dashboards invent their own vocabulary — “reach”, “views”, “engagement”. The platform does not. Meta’s status webhook reference defines five values, each with a one-line definition you can hold a vendor to.
| Status | Meta’s definition, verbatim | Carries pricing? |
|---|---|---|
sent | “Indicates the message was successfully sent from our servers.” | Yes |
delivered | “Indicates message was successfully delivered to the WhatsApp user’s device.” | Yes, on delivered or read |
read | “Indicates the message was displayed in an open chat thread in the WhatsApp user’s device.” | Yes, on delivered or read |
failed | “Indicates failure to send or deliver the message to the WhatsApp user’s device.” | No — carries errors instead |
played | “Indicates the first time a voice message is played by the WhatsApp user’s device.” | No |
“Replied” is not a status at all. A reply arrives as a separate inbound messages webhook with its own message ID, and nothing in the payload links it back to the template that prompted it. Reply attribution is something you build yourself, usually with biz_opaque_callback_data on the outbound message.
Delivered and read are different events — except when they are not
The subtlety that breaks most dashboards is in Meta’s documentation: “A status is considered read only if it has been delivered. In some cases, like when a user receives a message while in the chat screen, the message is both delivered and read at the same time. In these cases, the ‘delivered’ webhook is not sent because it’s implied that the message was delivered since it was read.”
So a message read instantly produces a read webhook and no delivered webhook. If your delivered count is the numerator and your sent count the denominator, your most engaged recipients each make that ratio worse. A delivered rate computed naively from webhook counts is biased downwards by exactly the behaviour you were hoping for.
The fix is not complicated — treat the statuses as a ladder per message ID and let read imply delivered — but it has to be a deliberate decision, and it is worth asking any provider whether they made it.
What a WhatsApp delivered vs read rate is a rate of
Webhooks are a delivery mechanism, not a ledger. Meta’s Graph API webhook documentation is blunt:
- Failed deliveries are retried “immediately, then try a few more times with decreasing frequency over the next 36 hours”.
- “Unacknowledged responses will be dropped after 36 hours.”
- Notifications are batched up to 1,000 updates, but “batching cannot be guaranteed”.
- Your server “should handle deduplication”.
- “You will not be able to query historical webhook event notification data.”
That last line is the one with teeth. There is no backfill. If your endpoint was down for an afternoon, those statuses are gone, and any read rate spanning it is computed against a denominator that quietly lost rows. Nothing in the API will tell you this happened.
A read rate is therefore a rate of read webhooks your system stored over messages your system believes it sent. That is a usable operational metric. It is not a measurement of human attention, and it is not comparable between two vendors unless both define it the same way — which is why we publish no engagement percentages of our own.
Your delivered count can fall with nothing broken
Meta applies a per-user limit to marketing templates. Its documentation says WhatsApp “may limit the number of marketing template messages a WhatsApp user receives from any business in a given period of time”, that the limit “adapts automatically over time based on a person’s recent engagement levels”, and that it “may mean delivering fewer messages to some WhatsApp users during periods of lower marketing read rates”. No number is published.
When it bites, the status webhook returns failed with error code 131049 and the title “This message was not delivered to maintain healthy ecosystem engagement.” That is not a template bug, a DLT problem or a provider failure, and retrying will not clear it — Meta’s documentation lists excessive retries as a trigger for the same code.
Two consequences follow. Meta is already using read rate as an input to delivery, so a falling read rate compounds; and your delivered count is partly a function of a system you cannot observe, which is a strong argument against writing it into an SLA.
Where each channel bills, and what it can see
The three channels businesses usually compare do not report the same things, and do not bill at the same point in the funnel.
| Channel | Billed at | Deepest signal defined | Read-equivalent? |
|---|---|---|---|
| Per delivered message, per AiSensy’s published card | read — displayed in an open chat thread | Yes | |
| SMS | On submission to the gateway | Delivery receipt, where the carrier returns one | No |
| Voice (28-second pulse) | On answer — “Charged only answered call” | Answered | No |
For SMS this is a protocol fact, not a vendor shortcoming. Twilio’s message resource documents a read status and states its supported channels are “RCS and WhatsApp”. Plain SMS has no display receipt to report, so any vendor quoting you an SMS open rate is quoting something the protocol cannot produce.
Voice is the same shape one step earlier. The bulk voice card we price against states “Charged only answered call” and, in the same block, “Delivery Ratio:- 100%” with no definition of the term anywhere on the page. Answered is a real event. Heard is not.
A worked example in rupees
One marketing template to 20,000 Indian contacts at AiSensy’s published rate of ₹1.09 per delivered marketing message, on its ₹3,200 Pro monthly plan:
- Messages: 20,000 × ₹1.09 = ₹21,800
- Plus platform fee: ₹21,800 + ₹3,200 = ₹25,000 before tax
- Plus 18% GST: ₹29,500, or ₹1.475 per contact charged
Now express that per read message: the per-contact figure divided by the share that was read.
| Reads per 100 charged messages | Reads | Cost per read message |
|---|---|---|
| 100 | 20,000 | ₹1.475 |
| 75 | 15,000 | ₹1.9667 |
| 50 | 10,000 | ₹2.95 |
| 25 | 5,000 | ₹5.90 |
Those denominators are illustrative arithmetic, not claims about what any list achieves. The point is the shape: halving the read share doubles the cost per read, and the ₹3,200 platform fee is ₹0.16 per message here — 14.68% of the ₹1.09 rate, and the part of the bill that falls fastest as volume rises.
The same send over SMS would be billed on submission: ₹0.25 per segment at Fast2SMS’s entry slab, so ₹5,900 including GST in English and ₹17,700 in Hindi, because a 160-character Devanagari notice is three UCS-2 segments rather than one. You would have no read figure to divide by at all. The full three-channel comparison is in SMS vs WhatsApp vs voice costs, and the layers of a WhatsApp bill in WhatsApp Business API pricing in India.
What to measure instead
Pick a denominator you control and state it. Cost per delivered message is defensible because you are billed on it. Cost per reply is defensible because a reply is an inbound webhook you can count without inference. Cost per completed outcome — a form finished, a survey answered — is the one that survives a finance review, which is the argument we make for IVR survey costs and bulk voice calls too.
Read rate belongs in the diagnostic column, not the headline: useful for spotting a template that stopped working, poor as a basis for a channel decision.
FAQ
What is a good WhatsApp delivered vs read rate? We do not publish one, and we would treat any vendor benchmark sceptically. No primary source publishes read rates by industry, the figures circulating in Indian WhatsApp marketing material trace back to vendor blogs rather than Meta, and two providers computing the ratio differently will produce different answers from identical traffic.
Does a user turning off read receipts suppress the read webhook? We could not verify this on 7 October 2026: WhatsApp’s consumer help centre is blocked to automated retrieval, and Meta’s developer documentation does not address the privacy setting’s interaction with business messaging. Treat a missing read as “no evidence” rather than “not read”.
Am I charged for a message that never reaches delivered? Meta’s pricing page does not state whether a template is charged on send or on delivery; AiSensy’s card describes its rates as “per delivered message”. The status webhook attaches a pricing object to sent and again to delivered or read, with a billable boolean, so the answer for your account is on your own invoice — check it against your webhook log.
Does WhatsApp tell me who replied to which campaign? Not on its own. Replies arrive as inbound webhooks with no reference to the outbound template. Set biz_opaque_callback_data when you send, store it against the message ID, and match on your side.
What does error 131049 mean? The message was suppressed by Meta’s per-user marketing limit. It is not a template or DLT problem, and retrying aggressively makes it more likely, not less.
Is played useful? Only for voice notes, where it marks the first playback. It does not apply to templates, and it is not an equivalent of a voice broadcast being heard.
A note on verification. Every figure here was checked against a live source on 7 October 2026; none was carried over from an earlier post. Rates change — re-check before acting on them. We sell messaging services, including WhatsApp, so treat the channel comparison as our reading of published cards rather than neutral testimony. Our own plans are at pricing.
Sources, all read 7 October 2026
- Meta, Status messages webhook reference — the five status values and definitions, the
pricingobject, the delivered-implied-by-read rule, and the 131049 example payload. - Meta, Per-user marketing template message limits — the adaptive limit, its read-rate dependency, error code 131049.
- Meta, Graph API webhooks, getting started — the 36-hour retry window, deduplication, batching, and the absence of historical queries.
- Meta, Pricing on the WhatsApp Business Platform — per-message pricing effective 1 July 2025; “Utility templates delivered within an open customer service window are free”; India local billing as of January 2026.
- AiSensy, Pricing — India rates effective 1 October 2026: marketing ₹1.09, utility, authentication and service ₹0.145, the last after 1,000 free per number per month, all described as per delivered message; Pro plan ₹3,200 a month.
- Twilio, Message resource — the
readstatus and its supported channels, “RCS and WhatsApp”. - Fast2SMS, Bulk SMS pricing — ₹0.25 per SMS at the ₹100–₹3,999 slab, covering promotional, transactional, service, OTP and API SMS.
- Bulk SMS Plans, Voice calls — transactional 28-second pulse slabs from ₹0.30, 18% GST on each slab, “Charged only answered call”.
- GST Council, An Overview of Telecom Services — telecom services under SAC 9984 at 18%.