> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# RCS brand verification KYC walkthrough

> Choose the right KYC path for RCS brand verification: which country rules apply to your brand, what the verification submit endpoint asks for, and when a reusable cprof compliance profile beats one-off uploads.

# 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](/guides/organization-kyc-onboarding) 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](/guides/rcs-onboarding) 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](/numbers/regulatory-preview) 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](/compliance/country-requirements) 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`:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/rcs/bots/bot_4kqzx1/verify \
  -H "X-API-Key: dv_live_sk_..." \
  -F 'data={"display_name":"Acme Retail"}' \
  -F "screenImages[]=@screens/welcome-card.png" \
  -F "screenImages[]=@screens/order-flow.png" \
  -F "kycdocs[]=@kyc/business-registration.pdf" \
  -F "document_type=business_registration"
```

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:

```bash theme={null}
# 1. Upload the file into the tenant-wide library once
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/documents \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -F "type=business_registration" \
  -F "country_code=BR" \
  -F "file=@/path/to/registration.pdf"
# → data.id: "doc_k7f2m9x1ab"

# 2. Create the profile with the RCS use case
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "RCS brand — Acme Brazil",
    "use_case": "rcs_brand_verification",
    "end_user_type": "business",
    "countries": ["BR"]
  }'

# 3. Attach the document by its doc_… ID, under the role the country asked for
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles/cprof_abc123/documents \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "document_id": "doc_k7f2m9x1ab", "role": "business_doc" }'
```

The [KYC documents lifecycle reference](/compliance/documents-kyc) 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](/compliance/documents-kyc#tenant-owned-by-design).

## 5. Cycle back to the compliance references

Keep these two pages open beside this guide:

* [KYC Documents & the Compliance-Profile Lifecycle](/compliance/documents-kyc) — the document library, roles, expiry, and the full `use_case` set that `rcs_brand_verification` belongs to.
* [Country Compliance Requirements](/compliance/country-requirements) — per-country and per-channel sender rules, including the RCS (`rcs_agent`) sender-type row and the `registration` levels that decide how early you must file.

Finish the org-level review too if live traffic is still gated — RCS brand verification never substitutes for it; the [organization KYC guide](/guides/organization-kyc-onboarding) covers that separate loop.