> ## 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 brands console: the dashboard path

> Register, edit, and resubmit RCS brands from Messages → RCS → Brands — how the form mirrors the brand API, where per-brand state lives, how to read moderation notes, and when the API is the better tool.

# RCS Brands Console: The Dashboard Path

The brand enrollment flow from the [RCS onboarding guide](/guides/rcs-onboarding) is fully clickable in the dashboard on the **Messages → RCS → Brands** page. The console and the API sit on the same endpoints, so a brand created through one surface is fully editable in the other — pick whichever fits the work.

## 1. The tab: Messages → RCS → Brands

Open **Messages → RCS → Brands**. Each registered brand renders as a card with its status badge, industry and country, website, contact person, and submitted date. **Create brand** opens the registration form; opening a card takes you to the brand's detail page, which tracks submission progress.

## 2. The form mirrors the API fields

The form under **Create brand** maps one to one onto the `POST /api/v1/rcs/brands` body:

* **Brand identity** — name, website, logo URL, industry vertical.
* **Contact person** — first and last name, email, phone, with an optional designation.
* **Postal address** — line 1 and 2, city, state or province, country, postal code.
* **Optional compliance fields** — tax ID and legal entity name. Carriers in some markets (for example India and Brazil) ask for these before approving an agent, so fill them in when you have them.

The form screens out an empty required field before anything submits. Save creates the draft and submits it for review in one step — the same create-then-submit pair the API walkthrough runs as two calls.

## 3. Where per-brand state lives

The badge on each card tracks the brand's state: **Draft**, **In review**, **Submitted**, **Approved**, **Rejected**, or **Suspended**. The detail page lays those out on a timeline — submitted → sent for review → decision.

Editable states match the API's conflict rules: a **draft** or **rejected** brand offers **Edit**; anything awaiting a decision stays read-only. A **draft** also carries **Delete** — removing it unlinks its agents rather than deleting them.

## 4. Moderation note vs API error

Two different rejections, two different answers:

* **A moderation note.** When a brand lands on **Rejected**, the card and the detail page both show the carrier or screening note inline — the `rejection_reason` you would otherwise read from the API. Fix the named fields and resubmit from the same page, either after editing or with **Resubmit as-is**.
* **An API error.** A failed create or update in the console surfaces the API's error payload inline — for example a `422` naming the invalid fields, exactly as the cURL examples receive it.

Read the note to repair submitted content; read the error payload to repair a request.

## 5. When to fall back to the API

The console handles the human path: register, curate, and resubmit one brand at a time. It thins for anything scriptable — a batch of brands across an agency's accounts, a CI-driven onboarding step, or a readiness probe from your own tooling. Those calls stay on `POST /api/v1/rcs/brands`, the count-only `GET /api/v1/rcs/brands/summary`, and the rest of the endpoints in the [RCS onboarding guide](/guides/rcs-onboarding), which the console itself consumes.

## Related

* [RCS onboarding](/guides/rcs-onboarding) — the full API path from brand to launch, plus verification, per-carrier launch, and reach sizing.
* [RCS channel page](/channels/rcs) — message shapes, rich cards, and the REST contract the console wraps.