RCS Brand Walkthrough: Create to First Send
The RCS onboarding guide documents every gate in the brand-to-launch registry: brand capture, agent creation, verification, per-carrier launch. This walkthrough runs one brand through the whole tree — fromPOST /api/v1/rcs/brands to a delivered rich card — so the parity gap with the WhatsApp getting-started guide closes on the brand path too. Use the API walkthroughs when you script; the console equivalents are named inline.
1. Why RCS needs a brand first
SMS sends start as soon as a number is live. RCS does not: every send goes out under a verified business agent, and carriers only launch an agent after they have reviewed the registered business behind it. Know-your-business screening lives on the brand record — name, website, industry, a contact person, and the postal address — so the first gate is a full brand payload, not just a sender id. Fill every field the first time: a rejected field restarts the review clock in days, not minutes.2. Create the brand
Console. Open Messages → RCS → Brands, click Create brand, and complete the form — the field map one-to-one onto the create call. Save creates the draft and submits it in one step. The console path is covered end to end in the RCS brands console guide. API. One payload carries the identity carriers review:201 with the brand in draft and the id (br_…) every later call references. Submit it with POST /api/v1/rcs/brands/:id/submit — submission is the gate to create the agent on it. Send tax_id and legal_entity_name even though the API marks them optional: carriers in markets like India and Brazil ask for them before approving an agent.
3. Verification and launch
Per-brand state machine, with the signal to poll at each step:
The verification call is
multipart/form-data: conversation screenshots under screenImages[] (up to 10), KYC documents under kycdocs[] (up to 5, one document_type label per file), and an optional brandLogoImage. India and Brazil ask for KYC proof at brand registration; a US-only brand may need nothing beyond the field block. The document choices and the reusable rcs_brand_verification compliance profile are the RCS brand verification KYC guide.
Launch is per carrier: the bot is sendable once carriers_launched ≥ 1, so compare the launched set against where your audience sits before you scale traffic.
4. Publish the first template
For campaigns and flows, author the definition as a stored template, not an inline payload — approval applies to the named template. Templates → New Template in the console (or the Rich Card Studio) does this visually; the API takes the same definition:rejection_reason inline. Two discipline rules: PUT on a template replaces the whole definition and resets approval, so land edits between campaign launches; and an inline rich card in a send is fine for one-off traffic, but anything a campaign sends repeatedly belongs in an approved template. Lifecycle sequencing lives in the RCS Templates tab guide.
5. First send, with SMS fallback
Once the bot showslaunched on at least one carrier and the template is Approved, send rich cards directly:
body instead of rich_card; a carousel of 2–10 cards uses rich_card_carousel. A single-card carousel renders as malformed — use rich_card for one card.
Fallback toggle. RCS → SMS fallback is org-level: open Settings → Channels → Cross-Channel Fallback and save a rule with Primary: RCS, Fallback: SMS. Once saved, every send that hits a non-capable handset, an unlaunched carrier, or an exhausted provider retries over SMS automatically — including a TCPA opt-out re-check before the SMS leg goes out. The /messages/rcs body accepts no per-request fallback field; keeping the chain on the organization makes it hold across the API, campaigns, flows, and inbox replies.
6. Status callbacks
Wire the delivery lifecycle through webhook events rather than polling the send response:
RCS sends emit the same envelope as every other channel, so one handler covers the mix. Read receipts are the RCS win over SMS:
message.read shows a card earned attention, which the per-template counters (Sent / Delivered / Read / Taps in the Templates tab) aggregate.
7. Common rejections
A brand or template rejection is not a dead end — the verdict carries arejection_reason, and re-submitting after a fix is safe. The patterns that recur:
- Trademark / brand-name mismatch. The brand name on the form does not match the website or the legal entity. Align the display name with public registration and re-submit.
- Evidence mismatch. The KYC document names a different entity than the brand fields, or a required document is missing or unlabeled. Attach the matching proof (or a compliance profile for repeat filings) and re-submit.
- Thin brand form. Contact person, address, or legal fields blank. Carriers reject thin forms; fill every field the first time.
- Link issues on templates. A malformed or non-HTTPS URL pair on a template action. Fix the URL and re-submit — approval resets on every edit.
Related
- RCS onboarding — the ordered path through every gate, plus tester devices, capability checks, and reach sizing.
- RCS brands console — the dashboard equivalents of each call above.
- RCS Templates tab — approval lifecycle and per-template deliverability.
- RCS brand verification KYC — document choices and the reusable compliance profile.
- RCS channel page — message shapes and the REST contract the walkthrough references.