Skip to main content

​
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 — 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: 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: 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:
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