RCS Brands Console: The Dashboard Path

The brand enrollment flow from the RCS onboarding guide 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.

Code sample: create and submit a brand

Authenticate with your tenant API key. Create the brand with POST /api/v1/rcs/brands, then pass the returned data.id to POST /api/v1/rcs/brands/{id}/submit. The API status is pending_review; the console labels that state In review.

cURL: create the draft

curl -i -X POST 'https://api.orbit.devotel.io/api/v1/rcs/brands' \
  -H 'X-API-Key: dv_live_sk_...' \
  -H 'Content-Type: application/json' \
  -d '{
    "brand_name": "Acme Retail",
    "brand_website": "https://acme.example.com",
    "brand_logo_url": "https://acme.example.com/logo.png",
    "industry_vertical": "Retail",
    "contact_first_name": "Ava",
    "contact_last_name": "Thompson",
    "contact_email": "ava@acme.example.com",
    "contact_phone": "+15550123456",
    "address_line_1": "100 Market St",
    "city": "San Francisco",
    "state_province": "CA",
    "country": "US",
    "postal_code": "94105",
    "tax_id": "US-123456789",
    "legal_entity_name": "Acme Retail, Inc."
  }'

A successful create returns 201 Created. Keep the returned data.id for the submit call:

{
  "data": {
    "id": "brand_01J8X4N2Q6M7R9T0V3W5Y1ZABC",
    "brandName": "Acme Retail",
    "status": "draft"
  },
  "meta": {
    "request_id": "req_01J8X4N2Q6M7R9T0V3W5Y1ZABC",
    "timestamp": "2026-10-10T12:00:00.000Z"
  }
}

cURL: submit the draft for review

curl -i -X POST 'https://api.orbit.devotel.io/api/v1/rcs/brands/brand_01J8X4N2Q6M7R9T0V3W5Y1ZABC/submit' \
  -H 'X-API-Key: dv_live_sk_...' \
  -H 'Content-Type: application/json'

The response is 200 OK; pending_review is the API value displayed as In review in the console:

{
  "data": {
    "id": "brand_01J8X4N2Q6M7R9T0V3W5Y1ZABC",
    "brandName": "Acme Retail",
    "status": "pending_review"
  },
  "meta": {
    "request_id": "req_01J8X4N2Q6M7R9T0V3W5Y1ZABC",
    "timestamp": "2026-10-10T12:01:00.000Z"
  }
}

Node.js and Python: complete create-then-submit flow

These dependency-light examples create the same draft, submit it, and check the tenant’s brand counts. The API key comes from an environment variable; do not put a live key in source control.

const baseUrl = 'https://api.orbit.devotel.io'
const headers = {
  'X-API-Key': process.env.ORBIT_API_KEY ?? 'dv_live_sk_...',
  'Content-Type': 'application/json',
}
const brand = {
  brand_name: 'Acme Retail',
  brand_website: 'https://acme.example.com',
  brand_logo_url: 'https://acme.example.com/logo.png',
  industry_vertical: 'Retail',
  contact_first_name: 'Ava',
  contact_last_name: 'Thompson',
  contact_email: 'ava@acme.example.com',
  contact_phone: '+15550123456',
  address_line_1: '100 Market St',
  city: 'San Francisco',
  state_province: 'CA',
  country: 'US',
  postal_code: '94105',
  tax_id: 'US-123456789',
  legal_entity_name: 'Acme Retail, Inc.',
}

const createdResponse = await fetch(`${baseUrl}/api/v1/rcs/brands`, {
  method: 'POST',
  headers,
  body: JSON.stringify(brand),
})
const created = await createdResponse.json()
if (!createdResponse.ok) throw new Error(JSON.stringify(created))
console.log('Created:', created.data.id, created.data.status)

const submittedResponse = await fetch(
  `${baseUrl}/api/v1/rcs/brands/${created.data.id}/submit`,
  { method: 'POST', headers },
)
const submitted = await submittedResponse.json()
if (!submittedResponse.ok) throw new Error(JSON.stringify(submitted))
console.log('Submitted:', submitted.data.status)

const summaryResponse = await fetch(`${baseUrl}/api/v1/rcs/brands/summary`, { headers })
const summary = await summaryResponse.json()
if (!summaryResponse.ok) throw new Error(JSON.stringify(summary))
console.log('Brand counts:', summary.data)

import os
import requests

base_url = "https://api.orbit.devotel.io"
headers = {
    "X-API-Key": os.environ.get("ORBIT_API_KEY", "dv_live_sk_..."),
    "Content-Type": "application/json",
}
brand = {
    "brand_name": "Acme Retail",
    "brand_website": "https://acme.example.com",
    "brand_logo_url": "https://acme.example.com/logo.png",
    "industry_vertical": "Retail",
    "contact_first_name": "Ava",
    "contact_last_name": "Thompson",
    "contact_email": "ava@acme.example.com",
    "contact_phone": "+15550123456",
    "address_line_1": "100 Market St",
    "city": "San Francisco",
    "state_province": "CA",
    "country": "US",
    "postal_code": "94105",
    "tax_id": "US-123456789",
    "legal_entity_name": "Acme Retail, Inc.",
}

created_response = requests.post(
    f"{base_url}/api/v1/rcs/brands", headers=headers, json=brand
)
created_response.raise_for_status()
created = created_response.json()
brand_id = created["data"]["id"]
print("Created:", brand_id, created["data"]["status"])

submitted_response = requests.post(
    f"{base_url}/api/v1/rcs/brands/{brand_id}/submit", headers=headers
)
submitted_response.raise_for_status()
print("Submitted:", submitted_response.json()["data"]["status"])

summary_response = requests.get(
    f"{base_url}/api/v1/rcs/brands/summary", headers=headers
)
summary_response.raise_for_status()
print("Brand counts:", summary_response.json()["data"])

A 422 response identifies invalid fields in error.details.issues. For example, an invalid email and a one-character country code are reported like this; correct each named field before retrying:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid input",
    "status": 422,
    "details": {
      "issues": [
        { "field": "contact_email", "message": "Invalid email address" },
        { "field": "country", "message": "Too small: expected string to have >=2 characters" }
      ]
    }
  },
  "meta": {
    "request_id": "req_01J8X4N2Q6M7R9T0V3W5Y1ZABC",
    "timestamp": "2026-10-10T12:02:00.000Z"
  }
}

For a count-only readiness probe, request GET /api/v1/rcs/brands/summary. It returns total, approved, and pending without fetching brand contact or address details:

curl -i 'https://api.orbit.devotel.io/api/v1/rcs/brands/summary' \
  -H 'X-API-Key: dv_live_sk_...'

The summary response wraps those counts in the standard envelope, for example { "data": { "total": 1, "approved": 0, "pending": 1 } }. For a no-code equivalent, use the console’s brand table, which lists each brand with its status and details.

3. Where per-brand state lives

The badge on each card tracks the brand’s state: Draft, In review, Submitted to Dotgo, Approved, Rejected, or Suspended. The detail page lays those out on a timeline — submitted → forwarded to Dotgo → decision. Editable states match the API’s conflict rules: a draft or rejected brand is editable and deletable; anything awaiting a decision stays read-only.

Per-state affordances

Each state unlocks a different set of actions, and the console mirrors the API’s conflict rules exactly — anything a button denies would also fail with a 409 on PATCH or DELETE:

State	Can edit?	Can delete?	Can resubmit?	Can link agents?
Draft	Yes	Yes	Yes — first submission	Yes
In review	No	No	Yes — Resend to review re-queues it	Yes
Submitted to Dotgo	No	No	No — a decision is in flight	Yes
Approved	No	No	No — nothing to resubmit	Yes
Rejected	Yes	Yes	Yes — with or without edits	No — the platform hold blocks new agents
Suspended	No	No	No — reversal is a platform support action	No — the platform hold blocks new agents

Two expectations to set:

Editing a rejected brand keeps the status Rejected until you submit again — the badge flips back to In review only on the next submission, not on save.
Resend to review (on an In review brand) is safe to click more than once: if the review has quietly advanced — the provider approved or refused while your view lagged — the click is a no-op and the page resyncs to the real status instead of resetting the queue.

The detail page: timeline, note, and the two resubmission paths

Opening a card lands on the detail page, which renders a three-step submission timeline: Submitted → Forwarded to Dotgo → Approved. Each reached step shows a timestamp; steps still awaiting a decision render as pending clocks, and on a Rejected or Suspended brand the unresolved steps flip to a fail marker. The full field payload — contact, address, compliance fields — renders below it. Two reviewer answers land inline on this page in different places:

When the brand lands on Rejected, the moderation note (rejection_reason in the API) renders in a red Rejection reason card, with two resubmission paths side by side. Edit and resubmit reopens the editable form so you can fix the named fields before resubmitting. Resubmit as-is puts the unchanged payload back into review — the right move when the note was a misunderstanding or a transient provider condition, and both paths land the brand back in In review either way.
A Draft brand gets a Submit for review button instead, and an In review brand gets the Resend to review card described above — degrade these paths to API fallbacks only when scripting.

Agent linking on delete

Deleting a draft or rejected brand does not cascade to its linked RCS agents. Agents point at the brand, and when the brand goes away the link is nulled — the agents are unlinked, not deleted, and stay listed under Settings → Channels → RCS for you to re-link to another brand or delete explicitly. The confirmation dialog states this before you confirm. Deleting an approved brand is not possible from any surface (a 409, per the table above), so this unlink path only ever applies to brands that never cleared review.

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, which the console itself consumes.

RCS onboarding — the full API path from brand to launch, plus verification, per-carrier launch, and reach sizing.
RCS channel page — message shapes, rich cards, and the REST contract the console wraps.

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

RCS brands console: the dashboard path

RCS Brands Console: The Dashboard Path

1. The tab: Messages → RCS → Brands

2. The form mirrors the API fields

Code sample: create and submit a brand

cURL: create the draft

cURL: submit the draft for review

Node.js and Python: complete create-then-submit flow

3. Where per-brand state lives

Per-state affordances

The detail page: timeline, note, and the two resubmission paths

Agent linking on delete

4. Moderation note vs API error

5. When to fall back to the API

​RCS Brands Console: The Dashboard Path

​1. The tab: Messages → RCS → Brands

​2. The form mirrors the API fields

​Code sample: create and submit a brand

​cURL: create the draft

​cURL: submit the draft for review

​Node.js and Python: complete create-then-submit flow

​3. Where per-brand state lives

​Per-state affordances

​The detail page: timeline, note, and the two resubmission paths

​Agent linking on delete

​4. Moderation note vs API error

​5. When to fall back to the API

​Related

RCS Brands Console: The Dashboard Path

1. The tab: Messages → RCS → Brands

2. The form mirrors the API fields

Code sample: create and submit a brand

cURL: create the draft

cURL: submit the draft for review

Node.js and Python: complete create-then-submit flow

3. Where per-brand state lives

Per-state affordances

The detail page: timeline, note, and the two resubmission paths

Agent linking on delete

4. Moderation note vs API error

5. When to fall back to the API

Related