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

# Plan campaign volume under carrier-assigned 10DLC throughput

> Read the T-Mobile Brand Daily Cap tier and the AT&T per-campaign MPM class the carriers assigned your vetted brand with GET /api/v1/compliance/10dlc/brands/:id/throughput, then size daily campaign volume, per-campaign pacing, and re-vet timing against those ceilings.

# Plan campaign volume under carrier-assigned 10DLC throughput

Once TCR vets your brand, the mobile network operators assign it real
send limits: T-Mobile a per-brand daily cap on message parts, AT\&T a
per-campaign messages-per-minute class. Orbit reads both from the
registry and returns them, derived from your brand's TCR trust score, on
`GET /api/v1/compliance/10dlc/brands/:id/throughput`. This guide walks
reading that assignment and planning campaign volume against it.

## Two tables: the pre-submit estimate and the carrier-assigned grant

The 10DLC path has two distinct throughput tables. Keep them separate:

* **Pre-submit, per-number estimate.** Before you file, the
  [preflight linter](https://docs.orbit.devotel.io/compliance/10dlc-preflight-linter.md) checks the
  expected volume you declare against a per-number estimate and warns
  when the two disagree. It is a filing aid: it scores the payload, it
  grants nothing.
* **Post-registration, carrier-assigned grant.** After the brand is
  vetted, the MNOs assign the limits below, keyed to the TCR trust
  score. These are the ceilings production traffic actually runs under,
  and they are what this page plans against.

| T-Mobile tier (Brand Daily Cap) | Trust-score floor | Daily cap |
| - | - | - |
| Sole Proprietor (entity type, any score) | any | 2,000 message parts/day |
| Low | 0 (baseline, includes unscored brands) | 10,000 message parts/day |
| Medium | 50 | 40,000 message parts/day |
| High | 75 | 200,000 message parts/day |
| Top | 100 | Unlimited |

| AT\&T class (per-campaign MPM) | Trust-score floor | Throughput |
| - | - | - |
| Class D | 0 | 15 messages/minute |
| Class C | 25 | 75 messages/minute |
| Class B | 50 | 240 messages/minute |
| Class A | 75 | 600 messages/minute |

Two structural facts shape every plan you build on these tables:

* The **daily cap is per brand**: it covers every campaign and number
  on the brand, so campaigns on one brand share one cap. The **MPM
  class is per campaign**: each campaign on the brand gets it
  independently.
* The cap counts **message parts**. A message that segments into three
  parts consumes three of your daily cap.

> [!NOTE]
>
> If TCR has not returned a score yet, the read reports the provisional
> standard grant (Low tier, Class C) with `provisional: true`. Plan on
> the provisional grant until the score lands, then re-read before you
> raise any pacing ceiling.

## Reading the assignment

Request the grant for a brand, passing the registered entity type and,
optionally, how many parts the brand has already sent in the current
24h window:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/10dlc/brands/B7F3A2/throughput?entity_type=PRIVATE_PROFIT&sent_today=36000" \
  -H "X-API-Key: $ORBIT_API_KEY"
```

**Response (`200 OK`):**

```json theme={null}
{
  "data": {
    "brandId": "B7F3A2",
    "provider": "telnyx",
    "vettingScore": 62,
    "vettingClass": "PASS",
    "vettedDate": "2026-09-14T09:30:00Z",
    "throughput": {
      "trust_score": 62,
      "provisional": false,
      "entity_type": "PRIVATE_PROFIT",
      "tmobile": {
        "tier": "MEDIUM",
        "daily_cap": 40000,
        "unlimited": false,
        "label": "Medium (40k message parts/day)"
      },
      "att": {
        "class": "B",
        "mpm": 240,
        "label": "Class B (240 MPM)"
      }
    },
    "consumption": {
      "daily_cap": 40000,
      "unlimited": false,
      "sent_today": 36000,
      "remaining": 4000,
      "percent_used": 90,
      "status": "warning"
    }
  }
}
```

A trust score of 62 clears the 50 floor on both tables: the Medium
daily cap and Class B. The `consumption` block is the read-back you get
only when you pass `sent_today`; without it, `consumption` is `null`.

**What "silently drops" means operationally.** T-Mobile does not return
an error when a brand crosses its daily cap. Parts above the cap are
filtered without a hard failure your send path can react to, so the
first symptom is downstream: delivery rates sag while sends report
accepted. The `consumption` read-back is how you see the approach
before it happens, in four bands: `ok` below 80% of the cap, `warning`
at 80%, `critical` at 95%, `exceeded` at 100%. Treat `warning` as your
planning signal, not `exceeded`: by the time the cap is consumed, the
overage is already being dropped.

## Sizing daily volume and pacing under the assigned tiers

Run both ceilings and plan to the lower one:

1. **Daily volume against the brand daily cap.** Sum the parts you
   expect across every campaign on the brand (messages times average
   segments) and keep the total inside the cap. On the Medium tier
   above, 40,000 parts/day is the outer bound for all campaigns on
   brand `B7F3A2` combined.
2. **Per-campaign pacing against the MPM class.** Each campaign may not
   exceed its class sustained. Class B's 240 MPM is 345,600
   messages/day in principle, so for most brands the daily cap binds
   long before the MPM class does; the MPM class binds when a single
   campaign bursts, for example a batch send at 09:00.
3. **Keep an internal target below the cap.** The carriers' filtering
   starts at the cap itself; schedule so a normal day lands in the
   `ok` band (below 80%) and a peak day stays under 100%.
4. **Splitting campaigns across a shared brand cap.** Because the cap
   is per brand, two campaigns on one brand compete for the same parts.
   Either budget daily volume per campaign and monitor the shared
   `consumption` read-back, or place high-volume traffic families on
   separate brands so each gets its own cap. Adding numbers to a
   campaign does not raise the daily cap; only a higher score or a
   different entity type does (see [Raising your tier](#raising-your-tier)).

Enforce the plan where sends run. The
[cross-schedule planner walkthrough](https://docs.orbit.devotel.io/guides/cross-schedule-planner-walkthrough.md)
spreads scheduled volume across send windows so a batch does not burst
through the MPM class, and
[campaign limits and quiet hours](https://docs.orbit.devotel.io/guides/campaign-limits-quiet-hours.md)
carry the per-campaign pacing controls. Where a lane uses per-channel
rate settings, [channel rate overrides](https://docs.orbit.devotel.io/compliance/channel-rate-overrides.md)
is the tenant configuration that caps it. Everything on the send side
is tenant-configured: Orbit enforces exactly the ceilings you set.

## Raising your tier

The score floors are the ladder: clear the next floor and the grant
rises with it (50 moves you to Medium and Class B, 75 to High and
Class A, 100 to the unlimited tier).

**When a re-vet helps.** `POST /api/v1/compliance/10dlc/brands/:id/revet`
requests a fresh grading of the brand. It helps when the underlying
brand record has genuinely changed since the last vetting: more traffic
history on the brand, corrected entity data, or a resolved rejection
pattern. The re-vet re-grades the brand against the same score-to-tier
contract shown above.

**When a re-vet cannot help.**

* It never changes the contract itself: the same score always maps to
  the same tier, on every brand, for every sender. If your score is
  stable, a re-vet returns a stable score and spends the re-vet fee for
  nothing.
* It does not lift the **Sole Proprietor ceiling**. A `SOLE_PROPRIETOR`
  brand is held at the 2,000-part daily cap and Class D regardless of
  score; that is a function of the entity type, not the grading.

**The sole-prop graduation path.** To leave the 2k ceiling, register
the brand as an organization entity (for example `PRIVATE_PROFIT`, with
the EIN the brand schema requires) so the score-derived tiers apply.
That is an entity-type change on a new filing, walked in the
[10DLC registration guide](https://docs.orbit.devotel.io/guides/10dlc-registration.md), not a re-vet of
the sole-prop brand.

## Planning around review latency

TCR sends no webhook when a re-vet completes. Orbit reconciles
non-webhook provider state every three hours, so the score, and with it
the tier the throughput read returns, updates on the next pass after
the registry re-grades the brand. The
[brand and campaign profiles walkthrough](https://docs.orbit.devotel.io/compliance/10dlc-brand-campaign-profiles.md#2-lifecycle-walkthrough--submit-brand-then-campaign-then-poll-status)
covers the same cadence for profile status; the manual
`POST /api/v1/compliance/compliance-profiles/:id/resync` forces a
re-read when you do not want to wait for the next pass.

Plan the sequence backwards from the date you need the volume: request
the re-vet days ahead of a ramp, confirm the new score on the vetting
read, confirm the new tier on the throughput read, and only then raise
the pacing ceilings you enforce on the send side. Raising pacing before
the tier read confirms the grant puts traffic into the silent-drop zone
on a cap that has not moved.

## What Orbit does not do

* Orbit reads and displays the carrier-assigned tier; it does not set,
  negotiate, or appeal it. The assignment is between your brand and the
  registry and the MNOs.
* Caps and silent filtering are MNO behavior. Orbit never guarantees
  deliverability at any tier; the read-back tells you where you stand,
  and the planning above keeps you inside it.
* There is no platform-side pacing mandate beyond what you configure.
  Per-campaign ceilings, schedule windows, and rate overrides are
  tenant settings; Orbit enforces exactly those and nothing hidden on
  top. Your registration posture stays tenant-owned, as on
  [brand and campaign profiles](https://docs.orbit.devotel.io/compliance/10dlc-brand-campaign-profiles.md).

## See also

* [10DLC registration](https://docs.orbit.devotel.io/guides/10dlc-registration.md) — brand and campaign
  filing, and the trust-score tier table
* [Free tool: 10DLC throughput & cost calculator](https://docs.orbit.devotel.io/guides/10dlc-throughput-calculator-tool.md)
  — the pre-registration estimator over the same tier tables
* [10DLC rejections and re-vet](https://docs.orbit.devotel.io/guides/10dlc-rejections-and-revet.md) —
  the decoder and the raw throughput read
* [10DLC preflight linter](https://docs.orbit.devotel.io/compliance/10dlc-preflight-linter.md) — the
  pre-submit expected-volume warning
* [10DLC brand and campaign profiles](https://docs.orbit.devotel.io/compliance/10dlc-brand-campaign-profiles.md) —
  the filing lifecycle and the 3-hour reconciliation cadence
* [Cross-schedule planner walkthrough](https://docs.orbit.devotel.io/guides/cross-schedule-planner-walkthrough.md) —
  spreading scheduled volume across send windows
* [Channel rate overrides](https://docs.orbit.devotel.io/compliance/channel-rate-overrides.md) — the
  tenant-configured per-channel rate caps


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.