Key points
- On Google's platform, delivery and read events come from the recipient's device; the RCS Message.in API delivers delivery reports to your webhook.
- Offline recipients are retried for up to 30 days unless the message expires or is revoked.
- Unreachable users (no RCS, or carrier not launched) are reported immediately, so fallback can start.
- Set an expiry (up to 15 days) for time-sensitive messages and revoke before sending SMS.
- Process events idempotently: duplicates and unusual orderings can happen.
What a delivery report tells you
When you send an RCS message, you get two kinds of feedback. First, the immediate response to the send request tells you whether the platform accepted the message. Then, on Google's platform, events are reported as things happen on the customer's device:
- Delivered — the message reached the device.
- Read — the customer opened it. Users can turn read receipts off, so read rates are a minimum, not an exact figure.
- Replies and taps — suggested-reply text, button postback data, shared locations and free-text answers.
Possible outcomes for a message
| Situation | What the platform reports | Sensible next step |
|---|---|---|
| Accepted, device online | Message delivered; a DELIVERED event follows | Wait for READ or a reply |
| Accepted, device offline | Platform keeps retrying for up to 30 days | Set an expiry so stale messages are revoked |
| Device or network can't receive RCS | Request rejected as not found | Send via fallback channel |
| Agent not launched on the user's carrier | Request rejected as not found | Send via fallback channel |
| Uses a feature the device doesn't support | Request rejected as invalid; not delivered | Simplify the message or use fallback |
| Expiry reached before delivery | TTL_EXPIRATION_REVOKED event | Treat as undelivered; trigger fallback |
Why “accepted” isn't the same as “delivered”
If a customer's phone is switched off or offline, the platform still accepts the message and keeps trying to deliver it for up to 30 days. That's helpful for a newsletter, but a one-time password or a same-day offer is useless days later. Count a message as delivered only when the delivery event arrives.
Expiry and revocation
For time-sensitive messages, set an expiry using either a time-to-live or an exact expiry time. The maximum is 15 days after submission; Google recommends at least 10 seconds. If the message isn't delivered before it expires, the platform tries to revoke it and reports the result. You can also revoke a message yourself at any time before it's delivered.
Because delivery and expiry are processed in parallel, Google notes rare edge cases where you might receive both a delivery and an expiry notification, or neither. Its guidance is:
- If a delivery event arrives, the customer has the message; ignore later expiry notifications for it.
- If expiry is confirmed as revoked, treat the message as undelivered and use fallback if needed.
- If the expiry result is inconclusive, use fallback for critical messages such as OTPs and decide case by case for others.
Designing SMS fallback
A dependable fallback flow looks like this:
- Choose an expiry per message type. Seconds to minutes for OTPs, hours for delivery updates, longer for informational campaigns.
- Send over RCS. If the response says the user can't be reached over RCS, send SMS straight away.
- Wait for delivery until the expiry. If the delivery event arrives, stop.
- Revoke, then fall back. Revoke the RCS message before sending SMS. If revocation fails because the message has just been delivered, don't send the SMS.
- Record the outcome. Store which channel delivered each message so reports and billing reconcile.
The SMS version must follow SMS rules. In India that means a registered sender header and a DLT-registered template, so prepare the fallback text in advance rather than trying to convert rich content automatically.
Capability checks
The platform can report whether a specific number can receive RCS and which features its device supports, provided the number has connected to RCS within the last 31 days. Bulk checks estimate how many numbers in a list are reachable. These are useful for planning, but conditions change, so a send-time result is still the final word.
Reading reports sensibly
- Compare delivered counts with your target list, not just with accepted requests, to see true RCS reach.
- Expect read rates to under-count because some users disable read receipts.
- Use tap and reply events to measure outcomes such as bookings or confirmations.
- Ask your provider how undelivered, revoked and fallback messages appear in reports and on invoices. Google states that, in its own billing reports, undelivered RCS messages aren't billed.
For integration requirements such as webhooks and idempotent processing, see the developer overview.