Sent, delivered, read: what each tick actually means
A message has four honest states: accepted by the provider, sent to the network, delivered to a device, and read by the app. Only the first is under your control, and none of them prove a person read your words.
The states, and what each actually proves
| State | What it proves | What it does not |
|---|---|---|
| queued / accepted | Your request was valid and is now our problem | That WhatsApp has it, or ever will |
| sent | It left for the network and was acknowledged | That the recipient's phone has seen it |
| delivered | It reached the recipient's device | That anybody looked at it |
| read | The app reported the conversation opened | That a human read or understood it |
| failed | Something refused it, with a reason | Whether retrying will help - that depends on the reason |
The three misreadings that cause real problems
Treating delivered as read
A dispatch team that treats delivered as "customer knows" will eventually deliver to a phone in a drawer and mark an order as confirmed. If the consequence of the customer not knowing is expensive, delivered is not the signal you want - a reply is.
Treating stuck on sent as a bug
A message that stays on sent for hours is usually a phone that is off. It can also be a block. Meta deliberately does not distinguish these, because a delivery report that reveals blocking would make blocking useless. Software that retries stuck sends because it assumes a bug will send the same message repeatedly to somebody who has blocked it.
A status is a fact with a timestamp, not a flag to flip. Statuses can arrive late and out of order. A system that overwrites delivered with a late-arriving sent will drag a finished message backwards - and if a retry loop watches that field, it will re-send a message the customer already has. Only ever move a message forward through the sequence.
Treating read receipts as reliable
Recipients can turn read receipts off. When they do, you will never see read for that person, forever, and no amount of investigation will find the bug - because there is not one. Any metric built on read rate has a silent, unmeasurable denominator.
What to build on instead
The only signal that means a human engaged is a reply. It is unambiguous, it cannot be turned off, and it opens a window you can use. If a process needs certainty, design it so the customer has to answer - "reply YES to confirm" is worth more than any number of ticks.
For everything else, delivered is the right operational bar: it means you did your part. Webhooks are how you learn about it without polling.
Questions people actually ask
Does delivered mean the person saw the message?
No. Delivered means it reached their device. They may not have opened WhatsApp. Read means the app reported it opened, and even that is not proof a person read the words.
Why does a message stay on sent forever?
Usually the recipient's device has not been online since. It can also mean the recipient blocked you, which looks identical from the outside - and that ambiguity is deliberate on Meta's part.
Should I retry a message that failed?
Only if the failure is temporary - a rate limit or a network error. Retrying a permanent failure such as an invalid recipient sends the same message to the same wall, and retrying without a deduplication key is how customers get the same notification four times.
Njiwa
One inbox for WhatsApp, Facebook and Instagram, and an API that sends over either WhatsApp rail. 7 days free, no card.