RCS API
RCS Business Messaging is the modern carrier-grade replacement for SMS on Android — rich cards, suggested replies, verified sender, read receipts. This surface registers your brand, creates verified agents, manages templates, and invites testers. Sending RCS messages themselves goes through the Messaging API atPOST /api/v1/messages/rcs.
Base path: /api/v1/rcs
Authentication: API key (X-API-Key) or session JWT.
Brands
A brand is the customer-facing entity that owns one or more RCS agents. Brand verification with the carrier is required before launch.Agents (bots)
An RCS agent (sometimes called a “bot”) is the actual sending identity — logo, color, contact info, and behavior. Agents must be verified before they can send to consumers.Test devices
Add specific phone numbers that can receive messages from an unverified agent — used during integration and QA.Templates
Pre-approved message templates with rich card components, suggested replies, and quick actions.Commerce (catalog carousel)
Turn your product catalog into a shoppable RCS carousel. List the products available to send, then render a selection into a rich-card carousel where every card carries an Add to cart chip and the message carries a single Checkout chip. Sends go through the standard messaging pipeline, so billing, delivery receipts, and scheduling apply exactly as they do for any other RCS message. Products come from the same Meta Commerce Manager catalog you connect for WhatsApp — one catalog serves both channels, so you do not configure a separate feed for RCS.List catalog products
Returns every product in your connected catalog. If no Commerce Manager catalog is connected yet,data.products is an empty array and data.count is 0 — an empty catalog is not an error, so your UI can render a “connect your catalog” empty state.
retailer_id is its SKU — that is the value you pass in product_ids when sending. Fields other than id are populated from Commerce Manager and may be absent for a given product.
Send a catalog carousel
Renders the selected products into a carousel and sends it to one recipient. Each product becomes one card — name, price, description, and image — with an Add to cart chip; products that carry a link also get a View chip. A single message-level Checkout chip closes the flow.
A carousel needs at least 2 products and shows at most 10. If your selection resolves to fewer than 2 products — for example a
product_ids list that matches nothing in the catalog — the request is rejected with 422. A selection larger than 10 is truncated to the first 10 (the RCS carousel limit).
202 Accepted with the queued message:
Capability check
Before sending RCS to a number, check whether the device + carrier supports it.Quality & analytics
Track how an agent is performing after launch: check its verification and per-carrier launch state, pull per-template and per-day engagement, and estimate how much of a segment can actually receive RCS before you spend on a campaign. Per-template and per-day numbers are aggregated from your own delivery receipts, so they reflect the samesent/delivered/read timestamps you see on individual messages. Windows are measured in whole days ending now.
Agent quality
Returns the verification and launch health of a single agent. Pass the agent’s id as{id}. Responds 404 if no agent with that id exists in your account.
launched is true once the agent reaches a launched state overall or on at least one carrier. carrier_statuses echoes each carrier’s raw status; carriers_launched and carriers_total summarise it so you can show “live on 1 of 2 carriers” without parsing the map.
Template analytics
Returns one row per template sent over the RCS channel in the window, ordered by volume. Messages sent without a template name collapse into a single(no template) row.
delivery_rate is delivered / sent, while read_rate and click_rate are over delivered (a handset cannot read or tap a card it never received).
Daily analytics
Returns one row per day in the window, oldest first, with the day’s RCS volume.Reach scan
Estimates what fraction of a saved contact segment can receive RCS through a given agent, so you can decide between RCS, a mixed RCS-with-SMS-fallback send, or plain SMS before you commit spend. It draws a bounded random sample from the segment and runs a live capability check for each sampled contact. Requires the owner, admin, or developer role — it reads contact phone numbers and runs billable capability lookups.sampled is how many contacts were actually probed (contacts without a phone number, and probes that error out, are excluded, so it can be lower than sample_size). reach_percent is capable / sampled. recommended_channel is a suggestion derived from that reach: rcs at 70% or above, mixed from 30–69%, and sms below 30%. An unknown bot_id or segment_id responds 404; a segment that resolves to no reachable contacts returns a zeroed summary rather than an error.
Test account
A sandbox flow for first-time testers — verify your own phone via OTP, then receive sample messages from an unverified agent.See also
- Channels → RCS guide — concepts, regional availability, fallback strategy
- Messaging API → Send RCS