> ## 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 and bot approval lifecycle

> Understand the tenant-owned identity checks, brand states, carrier verification, and launch gates that take an RCS bot from draft to live traffic.

# RCS brand and bot approval lifecycle

An RCS bot becomes eligible for live traffic through two related but separate reviews: your organization's identity review and the brand-level review carriers perform for the bot. The brand record holds the identity being reviewed; the bot verification submission carries the evidence; carrier launch is a second gate after verification.

This page explains that approval lifecycle only. Use [RCS capability checks and SMS fallback](/concepts/rcs-fallback-and-capability) for the recipient capability decision, and [the RCS channel reference](/channels/rcs) for message shapes, limits, and endpoint details.

## The two identity flows

### Organization KYC

Organization KYC is a workspace-level review. Submit it through [organization KYC onboarding](/guides/organization-kyc-onboarding). It verifies the business behind the workspace and can gate live traffic across channels. An approved organization does not make an RCS brand carrier-approved, and RCS brand verification does not replace organization KYC.

Complete organization KYC when the workspace's live-traffic gate requires it. Keep its status separate from the RCS brand and bot fields described below.

### Brand-level KYC

Brand-level KYC identifies the business represented by one RCS brand and agent. It starts from the brand record and is submitted with:

```text theme={null}
POST /api/v1/rcs/bots/:id/verify
```

The request can include screenshots, KYC documents, a logo, and a `data` JSON override. Carriers review this submission for the bot's brand. Brand-level verification gates the bot's carrier verification and therefore its ability to launch; it does not change the organization KYC result.

## The brand state machine

Create a brand with `POST /api/v1/rcs/brands`. A successful create returns `201` and starts the brand at `draft`. Complete the identity fields, then submit the brand with the brand submit action. The tenant controls that first transition; after submission, carrier/provider callbacks drive the review result.

The durable brand states are:

| State | Meaning | Who advances it | Terminal? |
| - | - | - | - |
| `draft` | The tenant is still completing the brand identity record. | Tenant creates or edits the brand. | No |
| `pending_review` / `submitted_to_dotgo` | The tenant submitted the brand and Orbit has placed it in the provider review flow. | Tenant submits; Orbit records provider handoff. | No |
| `approved` | The carrier accepted the brand identity. The linked bot can continue through bot verification and launch. | Carrier decision, reconciled from the provider callback. | No |
| `rejected` | The carrier refused the submission. Review the reason, edit the brand, and submit again. | Carrier decision, reconciled from the provider callback. | No |
| `suspended` | A previously accepted brand was taken down or paused by the carrier. It cannot be used for live traffic until the carrier restores it. | Carrier decision, reconciled from the provider callback. | Yes while suspended |

`approved` is a brand result, not a launch result. A bot still needs its own verification submission and a carrier launch on at least one network. `rejected` is recoverable: correct the identity or evidence and resubmit. `suspended` differs because it is a carrier takedown of an accepted brand; do not treat it as an ordinary draft edit or assume a resubmission alone restores traffic.

## `verification_status` and `launched` are separate gates

A bot has two orthogonal readiness signals:

1. **Verification:** `verification_status` must be `verified`. This means the carrier accepted the bot verification submission.
2. **Launch:** `carrier_statuses` must show `launched` for at least one carrier. This means at least one network has made the bot available for traffic.

Verification is necessary but not sufficient. Calling `POST /api/v1/rcs/bots/:id/launch` before `verification_status` is `verified` returns `409 INVALID_LAUNCH_STATE`. After a valid launch request, the bot can be `pending_launch` while carrier decisions arrive asynchronously. Read `GET /api/v1/rcs/bots/:id/quality` and inspect the per-carrier `carrier_statuses` map. Orbit reconciles provider callbacks into that read surface; do not depend on a provider bot-status endpoint that does not exist.

For live sending, require both `verification_status: "verified"` and at least one carrier entry with `status: "launched"`. A bot launched on only some carriers can reach subscribers on those carriers, not every RCS recipient.

## What the brand record carries

The brand row stores the identity fields carriers use to identify the business:

* `brand_name`, `brand_website`, optional `brand_logo_url`, and `industry_vertical`
* contact first and last name, email, phone, and optional designation
* `address_line_1`, optional `address_line_2`, `city`, optional `state_province`, `country`, and `postal_code`
* optional `tax_id` and `legal_entity_name`

The brand status, provider brand id, submission timestamps, and rejection reason are also retained. Update incomplete fields before submitting. If the contact or postal address is incomplete, the submit path returns `409`; no carrier document review can begin until those required identity fields are present.

## What the verification submission carries

The verify call carries proof and the bot's use context rather than replacing the brand record. A multipart submission can contain:

* `screenImages[]` — conversation screenshots showing the agent in use
* `kycdocs[]` — business or identity documents requested for the carrier set
* `brandLogoImage` — the logo used by the provider submission
* `data` — optional JSON overrides, including fields such as `video_url`

Keep the two responsibilities distinct: update the brand row when the business identity changes; attach documents and submission-specific evidence to the verify call. The [RCS brand verification KYC walkthrough](/guides/rcs-brand-verification-kyc) covers document selection and multipart examples.

## Reusable `cprof` compliance profiles

One-off uploads are appropriate for a single submission. If you register several agents, renew documents, or reuse the same business proof across carrier reviews, create a tenant-owned compliance profile with `use_case: "rcs_brand_verification"`. Attach the required documents to that profile and link the resulting `cprof_…` profile from the brand's verification configuration.

A reusable profile gives the tenant one place to maintain expiry and country-specific evidence. It does not bypass carrier review: the profile still moves through its own `draft` → `pending_review` → `approved` lifecycle, and the carrier decides whether the supplied evidence is sufficient. See [KYC documents and compliance profiles](/compliance/documents-kyc) for document roles and renewal rules.

## Rejection, suspension, and resubmission

After a `rejected` result, read the rejection reason, edit the brand fields that were wrong or incomplete, and submit the corrected identity and evidence again. Replace stale or insufficient documents rather than attaching the same rejected proof. A new submission returns the brand to the provider review path and the bot to a pending verification state; wait for `verification_status: "verified"` before launching again.

A `suspended` brand is different. It was accepted before the carrier paused or removed it, so the tenant should resolve the carrier's takedown reason and follow the carrier's restoration path. Do not represent a suspended brand as merely `draft`, and do not send live traffic while the brand is suspended. Carrier callbacks are the source of truth for the restored state.

## Worked example: create, verify, and launch

The following is the shape of one tenant's status progression. IDs and timestamps are illustrative; the status values are the values to branch on.

### 1. Create the brand

```http theme={null}
POST /api/v1/rcs/brands
```

```json theme={null}
{
  "data": {
    "id": "rcs_brand_acme",
    "brand_name": "Acme Retail",
    "status": "draft",
    "submitted_at": null
  }
}
```

Fill the contact and postal-address fields, then submit the brand. The provider handoff is represented by `pending_review` or `submitted_to_dotgo` while review is in progress.

### 2. Create the bot and submit verification

```http theme={null}
POST /api/v1/rcs/bots
```

```json theme={null}
{
  "data": {
    "id": "bot_acme_orders",
    "status": "draft",
    "verification_status": "created",
    "carrier_statuses": {}
  }
}
```

Submit `POST /api/v1/rcs/bots/bot_acme_orders/verify` with the required evidence. While the carrier reviews it, the quality response can show:

```json theme={null}
{
  "data": {
    "verification_status": "pending_verification",
    "launched": false,
    "carrier_statuses": {}
  }
}
```

After the provider callback is reconciled, the verification gate reads:

```json theme={null}
{
  "data": {
    "verification_status": "verified",
    "launched": false,
    "carrier_statuses": {}
  }
}
```

### 3. Launch and wait for a carrier

```http theme={null}
POST /api/v1/rcs/bots/bot_acme_orders/launch
```

The launch request is asynchronous. Until a carrier accepts it, the bot may report `verification_status: "pending_launch"` and `launched: false`. Once at least one carrier is live, the readiness response has the second gate:

```json theme={null}
{
  "data": {
    "verification_status": "verified",
    "launched": true,
    "carrier_statuses": {
      "310260": { "status": "launched" }
    }
  }
}
```

Only at this point should you treat the bot as ready for live RCS traffic, subject to the separate organization KYC and account-readiness controls.

## See also

* [RCS capability checks and SMS fallback](/concepts/rcs-fallback-and-capability) — capability probes and the SMS fallback decision.
* [The WhatsApp WABA lifecycle](/concepts/whatsapp-waba-lifecycle) — the parallel approval and readiness model for WhatsApp.
* [RCS onboarding](/guides/rcs-onboarding) — the ordered setup walkthrough.
* [RCS brand verification KYC walkthrough](/guides/rcs-brand-verification-kyc) — documents, country requirements, and reusable profiles.
* [RCS channel reference](/channels/rcs) — send contracts, limits, and channel-level endpoints.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.