RCS capability check: what it tells senders before they send

An RCS capability check tells you whether a phone number can receive RCS messages right now: the rich, app-free successor to SMS built into the phone's messaging app. It's a planning signal. It helps you size an RCS rollout, choose message formats and budget for SMS fallback. It isn't a delivery guarantee, and it doesn't mean your business sender can reach that number yet. This guide explains what capability discovery is, how iPhone fits in, how RCS falls back to SMS, and how to act on each answer.

#What is RCS, and what is capability discovery?

RCS (Rich Communication Services) upgrades the default messaging app with typing indicators, read receipts, high-resolution media and branded business messages. The GSMA's Universal Profile is the industry-agreed feature set for it, and it lists capability discovery first among its core features, alongside chat, group chat and file transfer (GSMA).

Capability discovery is how a phone or a sender learns, before sending, whether the other side can take part in RCS. Your messaging app does this in the background when it decides whether to show a chat as RCS or SMS. Business platforms expose it too. Google's RCS for Business documentation describes a capability check that returns the features a device supports, and advises that "if a user's device isn't capable of receiving RCS messages at all, you can communicate with the user through other services, such as SMS/MMS" (Google, 2026).

Our RCS capability check gives you the same yes/no answer for lists of numbers, without needing your own RCS agent first.

#Does iPhone support RCS?

Yes. Since iOS 18, released in September 2024, Apple's Messages app "supports RCS for richer media and more reliable group messaging compared to SMS and MMS" when messaging people who don't use an Apple device (Apple, 2024). Apple's support page adds two conditions: iOS 18 or later, and a text-messaging plan from a carrier that supports RCS on iPhone (Apple).

That's why our RCS answer can include device_os with ios or android when it's reported. It matters for design: rich cards and suggested replies can render differently across platforms, so preview on the handset mix you actually have.

One nuance for iPhone: between two Apple devices, Messages uses iMessage first. RCS is what an iPhone uses with non-Apple phones, and what it can receive from businesses. If you also want to know how many customers are on Apple devices, run the iMessage check in the same job.

#What is RBM, and why isn't capability enough?

RBM (RCS Business Messaging) is how brands send RCS: a verified sender, called an agent on Google's platform, sends branded, interactive messages through carriers. To reach a user, three things must be true:

1. The number is RCS-capable (what our check answers).
2. Your agent is verified and launched on the recipient's carrier.
3. The person agreed to receive your messages.

Google's documentation lists the two causes of a "not found" answer from its own capability endpoint: the user isn't reachable by RBM, for example because the device doesn't support RCS, or "the user has RCS, but your agent isn't launched on their mobile network" (Google, 2026).

So a capable number is a candidate for RCS, not a guaranteed recipient. Use our check to size the opportunity before you invest in an agent and carrier launches, and use your messaging provider's send-time capability check once you're live.

#How does RCS fall back to SMS?

RCS is designed to degrade gracefully. If a message can't go as RCS, a business platform or the handset falls back to SMS or MMS. The fallback decision needs rules, because the two channels differ in cost, features and length limits:

Write every RCS message with an SMS version from the start. Fallback shouldn't mean a truncated rich card. And an SMS fallback can fail for its own reasons, from invalid numbers to carrier filtering; our guide to why SMS messages aren't delivered walks through them.

#How fresh must a capability answer be?

Fresher than a messenger registration. Capability depends on the carrier, the handset, the messaging app and a user setting, and any of them can change. Google's documentation explains the mechanics on its side: a capability answer is returned only if the number "has connected to the RCS service within the last 31 days", online RCS devices check in "every 1–4 hours on average", and moving a SIM to another device replaces the old device association (Google, 2026).

It also notes that its bulk capability checks read from a cache updated by devices as people use RCS, so "results may not be current". The same caution applies to any capability data, including ours.

Practical rules:

• Refresh RCS answers before each major send, not monthly. Use a short max_age, such as one week.
• Keep the answer with checked_at and treat anything old as a hint only.
• Expect true to flip to false for customers who changed phones, and the other way round.

#How do I run an RCS check with the API?

The RCS check runs in bulk jobs only. POST /v1/lookup refuses it with 403 service_disabled. Create a job over your opted-in customers, with a short max_age:

curl https://api.mobilevalidate.com/v1/jobs \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rcs-campaign-2026-10" \
  -d '{"numbers": ["+447700900001", "+447700900002", "+447700900003", "+447700900010"],
       "checks": ["rcs"], "max_age": 604800}'
# then: GET /v1/jobs/{id}?wait=30 and GET /v1/jobs/{id}/results

The real test-mode job reported "progress": {"total": 4, "checks_total": 4, "done": 4, "conclusive": 3}. The answers per row:

{"e164": "+447700900001", "rcs.registered": {"status": "completed", "registered": true,  "reason": null}}
{"e164": "+447700900002", "rcs.registered": {"status": "completed", "registered": false, "reason": null}}
{"e164": "+447700900003", "rcs.registered": {"status": "unknown",   "registered": null,  "reason": "UPSTREAM_TIMEOUT"}}
{"e164": "+447700900010", "rcs.registered": {"status": "completed", "registered": false, "reason": null}}

Test answers don't include device_os; live answers include it when reported, and downloads add an rcs.registered.device_os column. For large lists, estimate first with the free POST /v1/jobs/estimate, and pass its max_cost to the job so it can never cost more. Only conclusive answers are billed, at the bulk price on the pricing page. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate).

#How do I estimate the business case for RCS?

Capability rates on your own base turn a vague "RCS is growing" into numbers you can plan with. From a job download, compute per country:

• Capable share = true ÷ (true + false). Leave unknowns out of both.
• Platform split among capable numbers, from device_os where reported.
• Expected SMS fallback volume = sends × (1 − capable share × share of carriers your agent is launched on).

A small worked example, with invented numbers for illustration: 100,000 opted-in customers in one country, 60% capable, and an agent launched on carriers covering 80% of them. About 48,000 customers could receive RCS; the other 52,000 messages go as SMS. If your RCS and SMS prices differ, this split is what drives your cost model. Our SMS cost reduction use case covers the wider picture.

Re-run the job before launch and a few weeks after. Growth in the capable share tells you whether to widen the rollout.

#What are the responsible-use rules?

RCS business messages are for people who agreed to receive them. Carrier and platform rules require verified senders and consent, and capability is never permission. This is general guidance, not legal advice; consult counsel about your own situation. Keep to these rules:

• Check only numbers you hold for a legitimate purpose, such as opted-in customers.
• Use device_os only for design and delivery. Don't infer anything about a person from their handset platform. Our acceptable use policy forbids profiling and inferring sensitive characteristics.
• No range scans. 20 or more consecutive numbers in one request are refused with 403 suspected_enumeration.
• Honour objections. People can object through our opt-out form; suppressed numbers are skipped and never charged.

RCS, iPhone and Google's platform are named descriptively. MobileValidate is not affiliated with the GSMA, Apple or Google.

#What are the key takeaways?

• An RCS capability check answers whether a number can receive RCS now: capable, not capable or unknown, sometimes with device_os.
• iPhone supports RCS since iOS 18 (2024), where the carrier supports it.
• Capability isn't reachability for your brand: your RBM agent must be launched on the recipient's carrier, and the customer must have opted in.
• Always write an SMS fallback. Unknown means "use the default", never "not capable".
• Capability changes quickly. Keep max_age short and refresh before big sends.
• Our RCS check runs in bulk jobs only. See the RCS check, the iMessage guide and the messaging-app checks guide.