The full A2P path: your application calls a provider’s RCS API → the provider sends the message as your verified RBM agent into the RCS backend (Jibe/carrier) → the backend delivers it to the user’s RCS client → user interactions (taps, replies, read receipts) flow back to your webhook. Anything that can’t be delivered as RCS automatically downgrades to SMS/MMS.
Because it’s IP-based, RCS needs a data connection and supports rich payloads (media, cards, buttons) and real-time signals (typing, read receipts) that the legacy SMS channel can’t carry.
It helps to see RCS as four layers stacked on top of each other, because a problem in a live program almost always belongs to exactly one of them.
| Layer | What it does | Who runs it |
|---|---|---|
| Client | Composes and renders messages, reports typing and read state | Google Messages, Apple Messages, Samsung Messages |
| Backend | Registration, capability discovery, routing, delivery, store-and-forward | Google Jibe for most of the world, a few carrier-run stacks |
| Sender platform | Agent identity, API, webhooks, fallback, billing | Your RCS provider |
| Application | Triggers sends and consumes events | Your code |
The capability check is the step that has no SMS equivalent, and it is worth understanding because it drives cost. Before a send, the platform asks the backend whether a given number is reachable over RCS on a device that supports the features the message needs. The answer is not simply yes or no: it is a feature list, which is why a carousel can be undeliverable to a handset that would happily accept a plain RCS text. Capability answers are cached rather than queried per message (SimplyRCS reuses a result for 24 hours per number and sender), so a phone that switched RCS on an hour ago may still be treated as SMS-only on the next send.
Delivery is store-and-forward, not a live socket. If the handset is offline the backend holds the message and delivers it when the device reconnects, which is why a delivery receipt can arrive hours after the send. Business senders normally set a time-to-live so a stale reminder expires rather than landing the next morning, and expiry then triggers the same fallback path as an outright failure.
Two behaviours regularly surprise teams moving over from SMS. Multi-device is one: RCS registration is tied to a phone number, and desktop or tablet clients mirror a primary device rather than registering separately, so a read receipt reflects whichever surface the person actually opened. Latency is the other. An RCS message travels over the public internet rather than the signalling channel, so it is usually faster than SMS but more variable, and it degrades on a weak data connection in a way SMS does not.
How RCS routing works follows a message through the capability check, what Universal Profile is covers the specification, and the RCS API overview shows the same flow from the sending side.
- Transport: IP (Wi-Fi/data); interoperability via GSMA Universal Profile; backend largely Google Jibe.
- Capability discovery decides RCS vs SMS/MMS fallback per recipient.
- Business path adds a verified RBM agent and a provider API + webhooks.
- A capability check returns a feature list, not a yes or no, and results are cached; SimplyRCS reuses one for 24 hours per number and sender.
- Delivery is store-and-forward; set a time-to-live so time-sensitive messages expire instead of arriving late.
- Registration is per phone number, and secondary devices mirror the primary rather than registering separately.