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 for the recipient capability decision, and the RCS channel reference 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. 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:

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:

Verification: verification_status must be verified. This means the carrier accepted the bot verification submission.
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 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 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

POST /api/v1/rcs/brands

{
  "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

POST /api/v1/rcs/bots

{
  "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:

{
  "data": {
    "verification_status": "pending_verification",
    "launched": false,
    "carrier_statuses": {}
  }
}

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

{
  "data": {
    "verification_status": "verified",
    "launched": false,
    "carrier_statuses": {}
  }
}

3. Launch and wait for a carrier

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:

{
  "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.

Getting Started

Channels

Channels (Voice)

AI Agents

Campaigns

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Brand & press

Changelog

RCS brand and bot approval lifecycle

RCS brand and bot approval lifecycle

The two identity flows

Organization KYC

Brand-level KYC

The brand state machine

`verification_status` and `launched` are separate gates

What the brand record carries

What the verification submission carries

Reusable `cprof` compliance profiles

Rejection, suspension, and resubmission

Worked example: create, verify, and launch

1. Create the brand

2. Create the bot and submit verification

3. Launch and wait for a carrier

See also

​RCS brand and bot approval lifecycle

​The two identity flows

​Organization KYC

​Brand-level KYC

​The brand state machine

​verification_status and launched are separate gates

​What the brand record carries

​What the verification submission carries

​Reusable cprof compliance profiles

​Rejection, suspension, and resubmission

​Worked example: create, verify, and launch

​1. Create the brand

​2. Create the bot and submit verification

​3. Launch and wait for a carrier

​See also

RCS brand and bot approval lifecycle

The two identity flows

Organization KYC

Brand-level KYC

The brand state machine

`verification_status` and `launched` are separate gates

What the brand record carries

What the verification submission carries

Reusable `cprof` compliance profiles

Rejection, suspension, and resubmission

Worked example: create, verify, and launch

1. Create the brand

2. Create the bot and submit verification

3. Launch and wait for a carrier

See also