Skip to main content

​
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 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.
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.
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:
Response (200 OK):
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).
Enforce the plan where sends run. The cross-schedule planner walkthrough spreads scheduled volume across send windows so a batch does not burst through the MPM class, and campaign limits and quiet hours carry the per-campaign pacing controls. Where a lane uses per-channel rate settings, channel rate overrides 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, 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 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.

​
See also