Skip to main content

​
RCS Brand Verification KYC Walkthrough

RCS runs two parallel identity flows, and picking the wrong one costs days of carrier-review time:
  • Org-level review — one approval per workspace that gates live traffic in general. The organization KYC guide covers it and says nothing RCS-specific.
  • Brand-level KYC — the documents and identity fields carriers review when they verify an RCS agent. This lives on the RCS verification submit call, not in the org form.
This guide is the choosing walkthrough for the second flow: how to find out what the countries on your launch list demand, what the RCS verification endpoint actually accepts, and when to build a reusable rcs_brand_verification compliance profile instead of attaching files to a single submission.

​
1. Where RCS brand KYC hooks in

The RCS brand endpoints (/api/v1/rcs/brands, /api/v1/rcs/bots) capture the identity carriers review — name, website, industry, a contact person, the postal address, and an optional tax ID and legal entity name. A create that passes validation stores the brand; a POST /api/v1/rcs/bots/:id/verify submission is where KYC documents attach. The separation matters for sequencing: the brand record carries the fields (who you are), and the verification submission carries the proof (documents backing those fields). A brand missing its contact or address block blocks verification with a 409 before any document is even read, so complete the brand fields first — the RCS onboarding guide walks that ordering. Carriers do not all ask for the same proof. India (Reliance Jio, BSNL, Vodafone Idea) and Brazil (Claro, Vivo, Tim) demand KYC verification at brand registration, while a US-only or EU-only brand may need nothing beyond the field block. Fill in tax_id and legal_entity_name when you have them even though the API marks them optional — the carriers that ask reject thin brand forms.

​
2. Check what a country asks for before you submit

Do not guess the document set. Two read surfaces tell you what a destination expects:
  1. Regulatory preview — GET /api/v1/numbers/regulatory-preview?country=BR&phone_number_type=local surfaces the document categories and structured fields a country requires, before you commit. The document roles it returns (id_proof, address_proof, business_doc, …) are the same roles KYC documents satisfy; see the regulatory preview reference for the field list and the role-to-upload-type mapping.
  2. Country rules — GET /api/v1/compliance/country-rules?channel=rcs lists per-country sender rules, registration levels, and content restrictions for the RCS channel specifically. A registration: required row means the market gates sends on an approved filing; read the country requirements page for how to interpret each field.
Run the preview for every country on the launch request before submitting verification — a carrier-side rejection restarts the review clock in days, not minutes.

​
3. Attach KYC documents to the verification submission

Verification expects files, so the request is multipart/form-data against POST /api/v1/rcs/bots/:id/verify:
Carrier-enforced limits: up to 5 kycdocs[] files (business registration, proof of address), up to 10 screenImages[] conversation screenshots, 5MB per file. The document_type text parts label each KYC file — send one entry per file, in the same order — because carriers reject unlabeled documents with a 400 document_type is required error. The optional JSON data field overrides values otherwise filled from the linked brand. Poll GET /api/v1/rcs/bots/:id/quality until verification_status reaches verified; launch requests before that return 409 INVALID_LAUNCH_STATE.

​
4. Choose the reusable profile route when you file more than once

One-off uploads on the verify call work when you register a single brand to a single carrier set. The moment you back several RCS agents (or expect renewals), move the same proof into a compliance profile with use_case: rcs_brand_verification — a structured identity bundle (cprof_…) that carriers review once and every covered sender reuses:
The KYC documents lifecycle reference lists every accepted use_case value — rcs_brand_verification among them — plus upload limits, roles, and renewal semantics. Documents expire: many regulators treat identity or address proof older than 3–12 months as stale, and a lapsed document stops counting toward a country’s requirements, so plan renewals from the profile where the same role gets a fresh upload before it lapses. rcs_brand_verification profiles are country-agnostic at the schema level (the field block makes countries optional for RCS), but name the countries your brand registers to anyway: the carrier-specific regimes (India, Brazil) are exactly the ones that read the country field. A profile moves draft → pending_review → approved, and only an approved profile satisfies a country’s checks. Approval is granted by the carrier or regulator, not by the platform; the platform stores, carries, and reports — supplying truthful documents stays with you. See the split recorded on the KYC documents page.

​
5. Cycle back to the compliance references

Keep these two pages open beside this guide: Finish the org-level review too if live traffic is still gated — RCS brand verification never substitutes for it; the organization KYC guide covers that separate loop.