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

# 10DLC brand & campaign compliance profiles

> How the sms_10dlc_brand_us and sms_10dlc_campaign_us compliance-profile use cases compose into a US A2P filing — brand first, campaign second, then poll the profile status — plus rejection handling, reusable KYC documents, and where 10DLC sits next to toll-free verification.

# 10DLC brand & campaign compliance profiles

For US A2P SMS over 10-digit long codes, registration is a **pair of
compliance profiles, not one**: a brand profile (who the sender is) and a
campaign profile (what the traffic is for). In Orbit both profiles live on
the shared compliance-profile model — they follow the same lifecycle, reuse
the same document library, and answer the same status endpoints as every
other packet. This page is the 10DLC-specific walkthrough of that model;
the concept anchor is
[10DLC: the US A2P sender-registration model](/concepts/10dlc-concept).

<Note>
  Compliance posture is tenant-owned. You choose which 10DLC profiles back
  which US traffic; Orbit enforces the lifecycle gates and the send-time
  check, and the approval itself always comes from The Campaign Registry
  and the carriers. Orbit never mandates that a US long-codes lane use a
  particular brand or campaign.
</Note>

***

## 1. `sms_10dlc_brand_us` vs `sms_10dlc_campaign_us` — what each profile controls

The two use cases register separately on
`GET /api/v1/compliance/compliance-profiles/use-cases` and carry
different packets:

* **`sms_10dlc_brand_us`** — the legal entity behind the traffic. The
  structured fields are the TCR brand schema: `entity_type` (PRIVATE\_PROFIT /
  PUBLIC\_PROFIT / NON\_PROFIT / GOVERNMENT / SOLE\_PROPRIETOR), display and
  legal company names, the EIN (required for every entity type except sole
  proprietor from the profile side), industry vertical, website, address,
  and contact details. No file documents are required for an organization
  brand — TCR grades the entity fields. The vetting outcome on the brand
  bounds the throughput your campaigns can request (T-Mobile brand daily
  cap, AT\&T per-campaign MPM class).
* **`sms_10dlc_campaign_us`** — the declared use case a brand sends under.
  The packet references an already-approved brand id and carries the use
  case (`MIXED`, `MARKETING`, `ACCOUNT_NOTIFICATION`, `CUSTOMER_CARE`,
  `DELIVERY_NOTIFICATION`, `FRAUD_ALERT`, `PUBLIC_SERVICE_ANNOUNCEMENT`),
  a 40–4096-character description, the consent/message flow text, sample
  messages, the HELP and STOP keyword responses, and embedded-link /
  embedded-phone / age-gated flags.

At send time the distinction matters: **the campaign is the gate**, the
brand alone does not open US A2P traffic. An unregistered or non-approved
campaign holding a `from` on a US long code is held before dispatch; the
brand profile on its own never satisfies it. Conversely, a campaign can
never reference a brand whose profile is not `approved` — resolver refuses
the attach.

***

## 2. Lifecycle walkthrough — submit brand, then campaign, then poll status

Work this order for a scripted filing (the
[10DLC registration guide](/guides/10dlc-registration) and the
[profile wizard walkthrough](/guides/compliance-profile-wizard) cover the
console flow; the [10DLC wizard](/guides/10dlc-wizard) handles sole-prop
OTP):

1. **Create the brand profile** as a `draft` with
   `use_case = "sms_10dlc_brand_us"` and brand fields in structured data:

   ```bash theme={null}
   curl -X POST https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles \
     -H "Authorization: Bearer $ORBIT_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "use_case": "sms_10dlc_brand_us",
       "data": {
         "entity_type": "PRIVATE_PROFIT",
         "display_name": "Acme",
         "company_name": "Acme Corporation Inc.",
         "ein": "12-3456789",
         "vertical": "TECHNOLOGY",
         "website": "https://acme.com",
         "address_street": "1 Market St",
         "address_city": "San Francisco",
         "address_region": "CA",
         "address_postal_code": "94105",
         "address_country": "US",
         "contact_name": "Compliance Lead",
         "contact_email": "compliance@acme.com",
         "contact_phone": "+14155551234"
       }
     }'
   ```

2. **Validate before submit** — every use case exposes its requirement set
   on `GET /api/v1/compliance/compliance-profiles/requirements?use_case=sms_10dlc_brand_us`;
   miss a required field and submit answers `422` with a `missing` list
   without ever reaching TCR.

3. **Submit the brand profile**
   (`POST /api/v1/compliance/compliance-profiles/:id/submit`); it enters
   `pending_review` and fans out to the TCR adapter.

4. **Wait for the brand to reach `approved`.** TCR brand vetting is
   typically 24–48h.

5. **Create the campaign profile** with
   `use_case = "sms_10dlc_campaign_us"`; its `brand_id` field carries the
   approved TCR brand id the first profile returned, plus the use case,
   description, message flow, sample messages, and HELP/STOP responses.
   Submit it the same way.

6. **Poll status on `GET /api/v1/compliance/compliance-profiles`** —
   filter by `use_case` and read the `status` of both profiles:

   ```bash theme={null}
   curl "https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles?use_case=sms_10dlc_campaign_us" \
     -H "Authorization: Bearer $ORBIT_API_KEY"
   ```

   TCR does not send webhooks for review transitions; Orbit reconciles
   non-webhook providers every three hours, so a status read returns the
   last reconciled value. The manual
   `POST /api/v1/compliance/compliance-profiles/:id/resync` forces a
   re-read if you do not want to wait for the next pass.

Both profiles follow the lifecycle map on
[Assemble a Shared Compliance Profile Across Gated Surfaces](/compliance/compliance-profile-assembly)
— the same `draft → pending_review → approved` guard states, the same
LOCKED/IN\_USE error codes on mutations past `draft`.

***

## 3. Rejection handling — common TCR codes and where they surface

A rejected brand or campaign profile moves to
`rejected` / `partially_rejected` (both stay editable) and carries the
registry's reason. The most common TCR rejection families:

* **`DUPLICATE-BRAND`** — a brand with the same entity/EIN is already on
  the registry; returned with `resubmit_allowed: false`, so the fix is a
  fresh filing, not an edit.
* **`BRAND-DCA-FAIL`** — the direct-carrier audit on the brand failed;
  also burns the brand id (`resubmit_allowed: false`).
* **Use-case mismatch** — the samples describe one kind of traffic while
  the declared use case says another (`MARKETING` samples under a
  `CUSTOMER_CARE` filing is the canonical form).
* **Consent/copy lint** — missing HELP/STOP responses, a `message_flow`
  that does not describe the opt-in, or an over-short description.

For a raw code string, decode it with
`POST /api/v1/compliance/10dlc/decode-rejection` — it returns the fixed
fix card the wizard banner uses, including whether the id is burned. The
full registry-vs-carrier split lives on
[10DLC rejections and re-vet](/guides/10dlc-rejections-and-revet), and
[Troubleshooting: 10DLC campaign rejected](/troubleshooting/10dlc-campaign-rejection)
is the operator runbook. The [wizard](/guides/10dlc-wizard) pre-lints
against the known rejection patterns before you spend a submission.

***

## 4. Doc requirements — which `doc_…` ids carry over

Documents live in the tenant-wide library independently of any profile
([KYC Documents](/compliance/documents-kyc)). The two 10DLC use cases are
unusually document-light:

* **`sms_10dlc_brand_us`** requires **no file documents** for an
  organization brand — TCR grades the entity fields themselves. A sole-
  proprietor brand verifies by phone OTP (walked on the
  [wizard guide](/guides/10dlc-wizard)), not an uploaded document.
* **`sms_10dlc_campaign_us`** accepts **one optional `other` role —
  opt-in proof**: a screenshot or copy of the consent flow a recipient
  sees before the brand messages them. Attach it with the same
  `doc_…` id + role attach any other profile uses.

Because the library is tenant-wide, the same `doc_…` id can back both
this campaign profile and any other packet that takes the `other` role —
and the business registration you uploaded for a `phone_number_purchase`
or `sms_sender_id_alphanumeric` profile stays available if a reviewer
asks for more than TCR's minimum.

***

## 5. US-market interplay — 10DLC next to toll-free verification

The US accepts exactly two sender identities for A2P SMS, and they pick
on different packets:

* **Long code (10-digit)** → the 10DLC pair — `sms_10dlc_brand_us` +
  `sms_10dlc_campaign_us`, registered through TCR.
* **Toll-free** → `sms_tfv_us`, Toll-Free Verification filed per DID on
  the dedicated TFV surface (Settings → Compliance → Toll-Free
  Verification), not through the shared-profile submit flow — the
  `/use-cases` catalogue carries an `available_via` deep-link for it.

The sender-identity classifier resolves each `from` to its class
(`long_code` vs `toll_free` come from different branches) and only then
picks the regime — a US long code cannot pass through TFV, and a
toll-free number is never graded by TCR. The decision tree lives on
[Sender-identity classification model](/concepts/sender-identity-classification-model);
the Regime registry row for US `ten_dlc` vs `toll_free` reads back on
[Country Compliance Requirements](/compliance/country-requirements).

***

## 6. Where the gate fires at send time — and why registration is tenant-owned

The 10DLC check runs **before dispatch**, like every gate on
[Send Gates](/compliance/send-gates): when a `from` resolves to a US long
code, Orbit verifies the brand-and-campaign pair's terminal status and
holds traffic the registry has not approved. The campaign profile — not
the brand, not the packet metadata — is what the gate answers against.

Registration is tenant-owned for the same reason every other packet is:
Orbit files what you submit and enforces the lifecycle transitions, but
it never auto-registers a US lane on your behalf and never decides that
a given sender must use a given brand. The carrier and registry
approvals are also theirs, not Orbit's — the
[throughput calculator](/guides/10dlc-throughput-calculator-tool) page
makes the same point about TCR's trust score.

***

## Related references

* [10DLC: the US A2P sender-registration model](/concepts/10dlc-concept) —
  the concept anchor this walkthrough hangs off.
* [10DLC registration](/guides/10dlc-registration) — the linear
  brand → campaign → status endpoints with the API contract.
* [10DLC wizard](/guides/10dlc-wizard) — resumable drafts, sole-prop OTP,
  pre-submit lint.
* [10DLC rejections and re-vet](/guides/10dlc-rejections-and-revet) — the
  decode-rejection fix card, registry-vs-carrier split, post-approval
  lifecycle.
* [10DLC marketing baseline](/guides/10dlc-marketing-baseline) — the
  send-path checklist once a campaign is approved.
* [KYC Documents & the Compliance-Profile Lifecycle](/compliance/documents-kyc) —
  the tenant-wide document library both profiles read.
* [Assemble a Shared Compliance Profile](/compliance/compliance-profile-assembly) —
  the shared lifecycle map and rotation path.
* [Compliance profile use cases](/compliance/compliance-profile-use-cases) —
  the full use-case catalogue and the country-pick matrix.
* [Sender-identity classification model](/concepts/sender-identity-classification-model) —
  how US long codes vs toll-free resolve to regimes.
* [API Reference → Compliance](/api-reference/endpoints/compliance) — the
  profile endpoint surface.