Skip to main content

​
Sender warming and reputation

Carrier abuse filters punish one pattern above all others: a fresh origination identity ramping straight to full volume. Orbit’s answer is a two-layer warming system — a graduated daily-volume ramp that grows a new sender’s ceiling over its first weeks, and two scores (trust and reputation) that decide how fast the ramp advances and when it holds. This page explains what warming is, how the curve moves, and how the scores differ. The endpoint-by-endpoint contract lives in Number health, warming, and carrier reputation tracking; this page is the model behind it. For the step-by-step ramp walkthrough, see the number warming guide. Warming is advisory rate-limiting, not a carrier guarantee. The ramp meters a sender toward volumes the carrier ecosystem tolerates; it does not promise acceptance, and it never blocks a send the carriers themselves would carry.

​
What warming means in Orbit

When a new number starts sending in the US 10DLC ecosystem, The Campaign Registry and the downstream carriers cap daily throughput to a tier your brand has earned. Orbit runs two complementary ramps on top of that:
  1. The trust-tier cap — the carrier-published phase table (initial → ramp → steady → verified). Each phase carries a daily SMS ceiling, and phase advancement is driven by your 10DLC trust score: registration is incomplete at first, and the ceiling climbs as the trust score rises and the number ages.
  2. The operator-driven growth curve — a geometric ramp over days-since-warming started, independent of the trust tier. It covers the early window where the carrier table still looks like a step function: day zero starts small and compounds roughly a third per day until it reaches the number’s hard ceiling, then the warming lifecycle flips from warming to warmed and the gate no-ops.
Both gates can bind on the same send. On a fresh number the growth curve is usually the tighter of the two for the first two weeks; after the curve tops out, the trust-tier phase ceiling is the one that matters. Exceeding the trust-tier cap returns DAILY_CAP_EXCEEDED; exceeding the growth curve returns WARMING_QUOTA_EXCEEDED with a retry_after. The four phases, in canonical order: The warming dashboard card and the GET /api/v1/numbers/:id/warming endpoint report the current phase, today’s daily_cap, the live current_day_count, the trust_score, and warming_started_at.

​
The per-number meter

The per-DID meter has five moving parts:
  • daily_cap — today’s ceiling after both gates: the trust-phase table intersected with the growth curve, then scaled by carrier feedback (below).
  • current_day_count — sends so far in the current UTC day. The counter resets at 00:00 UTC; a warmed-off number keeps an idle mirror so the dashboard still renders.
  • warming_phase — where the number sits in the trust table above.
  • trust_score — the 10DLC trust score the registration ecosystem assigned your brand; it moves the phase ceiling, and nothing else.
  • warming_started_at — the anchor the growth curve compounds from. Re-toggling warming does not rewind the anchor.
To plan a launch, read the forecast instead of polling day-by-day: GET /api/v1/numbers/:id/warming/progression returns warming_state, warming_started_at, warming_max_daily_sms, and a 15-day forecast of the daily ceiling. Worked example — a fresh DID with the default curve (day 0 = 50, ~35% daily compounding, hard cap 3,000): If the forecast line flattens below its base curve, carrier feedback is holding the ramp — read the health tier before assuming a bug.

​
Alphanumeric sender-ID and international long-code warming

The per-DID engine keys on phone_numbers rows, so it never covered the origination identities that dominate EMEA/MENA corridors: alphanumeric sender IDs ("ACME", "OTP") and international long codes. The sender warm-up surface closes that gap with a parallel pair of endpoints:
returns a warm-up meter for every warmable sender the tenant sends from, busiest first; GET /api/v1/messages/senders/warmup/lookup?sender=ACME drills into one sender and adds a day-by-day forecast of the ceiling curve for the dashboard chart. Each row classifies the sender into a scope: alphanumeric and international_long_code are warmed here; domestic_10dlc is excluded (the number-warming engine owns it) and short_code is excluded (short codes are pre-vetted from day one). For warmable scopes the meter reports days_active, a recommended_daily_ceiling on the geometric ramp, warmup_complete once the curve has topped out, and a reputation score with tier. Two properties make the sender meter directly comparable to the per-DID meter:
  1. Same reputation kernel. The sender’s reputation is computed over the same 30-day DLR window and the same delivered/failed/complaint semantics the per-number health score uses. A 42 on a sender ID means the same thing as a 42 on a DID.
  2. Same curve shape. The graduated ramp is the same base × growth^days family, tuned to the higher steady-state volume a corridor-wide brand sender carries (a much larger day-0 base and hard cap than a single DID). The response echoes the ramp constants in ramp, so a forecast stays honest across versions.
Because both surfaces derive reputation and days-active from the tenant’s messages table with no new persisted state, the sender meter is a pure read — you get the safety net without a migration step.

​
Reputation score vs trust score

The two scores answer different questions, and conflating them causes real operational mistakes: The reputation score is recomputed daily by a scheduler from delivery receipts (DLRs) and persisted onto the number as a 0–100 score plus a tier (excellent | good | fair | poor | critical, unknown when the sample is too thin). Complaint-coded carrier rejections count heavily against it. That tier feeds the closed loop on every warming gate:
  • excellent / good / fair / unknown → the ramp proceeds at the full base curve (1.00 factor).
  • poor → the ceiling holds at 50% of the curve (holding state).
  • critical → the ceiling throttles to 25% of the curve (throttled state), with a floor at the day-0 base so a recovering sender can always accrue fresh receipts.
The factor is always at or below 1: carrier feedback can only pull the ramp back, never lift it above the fixed curve. Practically: the trust score decides how big you may get; the reputation score decides whether the ramp lets you get there right now.

​
What warming is not

Keep the boundary explicit when you build on these meters:
  • Warming caps, it never rewrites. The gates reject an over-cap send with a quota error; they never alter the destination, the sender identity, or the route. Every outbound send still exits through the Devotel softswitch — warming sits in front of the path, it is not an alternate path.
  • Scores are own-traffic only. The reputation score is derived from the tenant’s own delivery receipts; it does not read carrier-published spam labels. For the carrier-side label on your outbound numbers, pair it with the reputation surfaces and, for forward risk, the spam-likelihood endpoint.
  • Sender warm-up is advisory. The sender-ID meter returns a recommended ceiling and a ramp state; it does not black-hole traffic. Treat recommended_daily_ceiling as the pacing input for your campaign throttle, not as a hard refusal.

​
See also