> ## 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.

# Brand identity and trust score: the cross-channel verification rollup

> How Brand Identity rolls the per-channel compliance posture of 10DLC, toll-free, WhatsApp, RCS, branded calling, and number KYC into one trust score and a prioritized next-action list, and how to run it in your ops workflow.

# Brand identity and trust score

Every regulated channel carries its own brand-registration flow: 10DLC brand and campaign, toll-free verification, WhatsApp Business verification, RCS verified sender, branded calling (RCD/CNAM), and per-number regulatory KYC. Each one lives in a different registry, reports its status in its own vocabulary, and has its own settings page. Brand Identity reads the current state of all of them and rolls them into one **trust score** plus a **prioritized next-action list**, so you answer "how verified is our brand, everywhere?" from a single surface instead of six.

Brand Identity is a read-only hub. It never changes anything you register; it reports what you have registered. The endpoint contract lives in the [Brand Identity API reference](/api-reference/brand-identity) — this page explains the model and how to run it in practice.

## What the hub rolls up

Six sources feed the rollup, each with a stable channel key:

| Channel key           | What it registers                                                        | Registration surface                                         |
| --------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------ |
| `messaging_10dlc`     | Your 10DLC brand and campaign registrations with The Campaign Registry.  | [10DLC registration guide](/guides/10dlc-registration)       |
| `messaging_toll_free` | Toll-free verification (TFV) for US/Canada toll-free SMS.                | [Sender-ID registration](/compliance/sender-id-registration) |
| `whatsapp_business`   | Meta's Business verification for your WhatsApp sender.                   | [WABA setup guide](/guides/whatsapp/waba-setup)              |
| `rcs_business`        | The verified-business-sender check RCS carriers expect.                  | [RCS channel page](/channels/rcs)                            |
| `branded_calling`     | RCD/CNAM branded calling, so recipients see your name on outbound calls. | [CNAM page](/numbers/cnam)                                   |
| `number_regulatory`   | Per-number regulatory KYC documents for countries that require them.     | [Regulatory preview](/numbers/regulatory-preview)            |

Each channel reports one of five states:

* `verified` — registration approved and active.
* `in_progress` — a submission is pending review with the registry.
* `action_required` — the registry bounced something back, and a fix is pending.
* `not_started` — you have never submitted.
* `unavailable` — the underlying subsystem could not be reached on this read.

`not_started` and `in_progress` are where most gaps come from; `action_required` is the one to fix first, since a registry has already rejected something it had approved expectations for.

## How the trust score is computed

The score is `verified / applicable`, rounded to an integer 0–100, where `applicable` is the count of channels that returned a real state. The counters land in `summary`: `applicable`, `verified`, `inProgress`, `actionRequired`, `notStarted`, `trustScore`, and an `overallState` derived from the worst channel state.

The formula is deliberately simple. Every channel counts equally — that is the point of the rollup: a brand that is verified on SMS but unregistered on WhatsApp still carries a partial posture, and weighting games would obscure that. A per-request weighting, if you need one, belongs in your own scoring on top of the API response.

Reads are fail-soft. If one source subsystem times out, it comes back as `unavailable` and drops out of the denominator instead of blanking the whole response or zeroing the score. You get the other five channels plus a complete summary, and the score reflects the sources that actually answered. Weights that fail to load never silently trash your number.

Which sources to register, and whether a low score matters to you, is your call as the tenant. Brand Identity is a reporting surface — it surfaces your posture so you decide what to complete, in what order. It does not gate sending, and it never blocks a send that the registry itself still allows.

## Reading the next-action list

Alongside the numeric score, the endpoint returns `nextActions`: every channel that is not yet verified, sorted `urgent` before `todo`, each with the route to the surface where you fix it.

* **Urgent** maps to `action_required` — a registry rejected or is blocking something. Fix it ahead of anything merely incomplete.
* **To do** maps to `not_started` or `in_progress`.

Each action carries the channel key, a human label, and an `href` into the dashboard. Map each action to its fix surface:

| Action channel        | Fix surface                                                                                       |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| `messaging_10dlc`     | [10DLC registration guide](/guides/10dlc-registration) (re-vet after correcting the brand record) |
| `messaging_toll_free` | [Sender-ID registration](/compliance/sender-id-registration)                                      |
| `whatsapp_business`   | [WABA setup guide](/guides/whatsapp/waba-setup)                                                   |
| `rcs_business`        | [RCS channel page](/channels/rcs)                                                                 |
| `branded_calling`     | [CNAM page](/numbers/cnam)                                                                        |
| `number_regulatory`   | [KYC documents](/compliance/documents-kyc) for that number's country                              |

When an action disappears from the list, the channel reached `verified` — refresh the status call and watch the score climb.

## Pull your posture

One read, one trust score:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/brand-identity/status \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

```json theme={null}
{
  "data": {
    "summary": {
      "applicable": 6,
      "verified": 3,
      "inProgress": 1,
      "actionRequired": 1,
      "notStarted": 1,
      "trustScore": 50,
      "overallState": "action_required"
    },
    "channels": [
      {
        "key": "messaging_10dlc",
        "label": "10DLC messaging",
        "pillar": "messaging",
        "state": "verified",
        "detail": "Brand + campaign approved",
        "reason": null,
        "verifiedAt": "2026-04-02T10:00:00.000Z",
        "manageHref": "/settings/compliance/10dlc"
      }
    ],
    "nextActions": [
      {
        "channel": "whatsapp_business",
        "label": "Complete WhatsApp Business verification",
        "href": "/settings/compliance/whatsapp",
        "priority": "urgent"
      }
    ]
  },
  "meta": { "request_id": "req_abc123", "timestamp": "2026-06-18T14:09:00.000Z" }
}
```

Field by field:

* `summary.applicable` — channels that answered this read. The denominator for the score.
* `summary.verified` — channels in `verified` state. The numerator.
* `summary.inProgress` / `actionRequired` / `notStarted` — the breakdown of what is left.
* `summary.trustScore` — `verified / applicable` rounded (here, 3 of 6 = 50).
* `summary.overallState` — worst-case state across channels; `action_required` here because one channel needs a fix.
* `channels[].key` / `label` / `pillar` — which channel you are looking at, and whether it belongs to messaging or voice.
* `channels[].state` — one of the five states above.
* `channels[].detail` — a plain summary of the registry's current answer.
* `channels[].reason` — when a registry rejected something, why; `null` otherwise.
* `channels[].verifiedAt` — when the channel reached `verified`.
* `channels[].manageHref` — the dashboard route where that channel is managed.
* `nextActions[]` — the unresolved channels, urgent first.
* `nextActions[].priority` — `urgent` on `action_required`, `todo` on `not_started` / `in_progress`.

Diff the response against your stored snapshot over time — `verifiedAt` moves forward as a channel completes, and `nextActions` drains as gaps close.

## Using it in ops

The same endpoint backs the **Brand identity & trust** panel on *Settings → Compliance* in the dashboard: trust-score progress bar, a state chip per channel, and the prioritized list. Because the API accepts any authenticated role — `owner`, `admin`, `developer`, or `viewer` — everyone on the team can read posture in either surface; the fix links land on the role-appropriate pages.

A practical cadence:

1. Read the score in your weekly ops review. Track the trend, not the snapshot.
2. Drive the backlog off `nextActions` — urgent items first, complete gaps second.
3. Build on the API rather than scrape the dashboard if you are automating: alert on a trust-score drop beyond a threshold, or on `actionRequired > 0`.

One scoping note. The trust score is the organization-level rollup and is only as granular as the six channel checks. It complements — never substitutes — campaign-level vetting: the per-brand TCR vetting score on 10DLC sets your US throughput tier, and per-number KYC still gates individual DIDs. Account for both layers when answering "what's our verified posture this week?"

## See also

* [Brand Identity API reference](/api-reference/brand-identity) — the endpoint contract this concept page explains
* [10DLC registration guide](/guides/10dlc-registration) — the highest-yield rollup source to complete first
* [Sender-ID registration](/compliance/sender-id-registration) — toll-free and alphanumeric sender posture
* [Regulatory preview](/numbers/regulatory-preview) — pre-flight per-number KYC requirements
* [Compliance → privacy register](/compliance/privacy-register) — tenancy-level generic posture register
* [Glossary](/reference/glossary) — definitions of **Trust Score** and **Brand Vetting / Vetting Score**