Delivery Receipt

Sent vs delivered vs read — three different truths

These three statuses are often conflated, but each answers a distinct question and each fires a separate webhook. 'Sent' only tells you your request was well-formed and accepted — it is an internal handshake, not proof of reach. 'Delivered' tells you the message left WhatsApp's queue and arrived on a real, reachable device. 'Read' tells you the recipient actually opened it, and it depends entirely on the user having read receipts enabled — many people switch them off, so a low read rate is not the same as poor delivery. For measuring reliability, delivered is the metric that matters: it isolates infrastructure and deliverability from human behaviour. If a message sits at 'sent' and never advances to 'delivered', the recipient's device is unreachable — powered off, out of coverage, or the number is not on WhatsApp.

Why delivery receipts matter for cost on today's WhatsApp

Since 1 July 2025, Meta bills the WhatsApp Business API per delivered message, priced by category — marketing, utility, or authentication —. This replaced the older per-conversation model, and it makes the delivery receipt the event that maps most directly to what you pay. The 24-hour window that opens when a customer messages you still exists, but it is now a free service window for back-and-forth support replies, not a billing unit. In practical terms: a template message that reaches a device counts; a message stuck at 'sent' that never delivers does not become a delivered charge. Tracking delivery receipts therefore does double duty — it is your reliability dashboard and your cost ledger. InfiQ surfaces delivered status per message and applies transparent ₹ pricing (ex-GST), so the number of delivery receipts you generate lines up cleanly with your invoice.

How to capture and act on delivery receipts

To use delivery data programmatically you register a webhook endpoint with your WhatsApp Business API provider; WhatsApp then POSTs a status object each time a message advances through sent, delivered, read, or failed. Well-built systems store these against the original message ID and use them to drive real decisions — retry logic, suppression of unreachable numbers, and accurate delivery-rate reporting. A healthy delivery rate on clean, opted-in lists is typically very high; a sudden dip is an early-warning signal worth investigating before it drags down quality rating.

• Log every status webhook against its message ID for a full audit trail
• Alert when delivery rate falls below your normal baseline — it often precedes quality-rating drops
• Suppress numbers that repeatedly fail to deliver instead of re-sending to them
• Never treat 'sent' as success in reporting — always reconcile to 'delivered'

Common mistakes and misreadings

The most frequent error is treating the single tick ('sent') as delivery — it only means WhatsApp accepted the request. The second is reading absence of blue ticks as failed delivery; a message can be reliably delivered yet never marked read because the recipient disabled read receipts. Teams also misattribute low delivery rates to their platform when the real cause is list hygiene: messaging numbers that are not on WhatsApp, are invalid, or never opted in. Another trap is ignoring the 'failed' webhook and its error code, which frequently pinpoints the exact issue — an unregistered number, a policy block, or a template problem. Finally, some assume every delivered message was 'seen'; delivery is a device-level fact, not a human-attention one, so keep delivery and read metrics separate in every report.