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

# Sender warming and reputation: how the ramp and trust kernels work

> How Orbit's graduated sender-warming ramp, the four warming phases, and the DLR-driven reputation and trust scores fit together across 10DLC numbers and alphanumeric sender IDs.

# 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](/numbers/health); this page is the model behind it. For the step-by-step ramp walkthrough, see the [number warming guide](/guides/number-warming).

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:

| Phase      | What it means                                                                                                                   | Typical ceiling                  |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| `initial`  | The linear on-ramp: the first \~14 days from `warming_started_at`, climbing from a small day-0 floor                            | \~100 → 2,000/day                |
| `ramp`     | Low trust score (0–50): the carrier table holds you at a few thousand per day while vetting catches up                          | \~2,000–4,000/day                |
| `steady`   | Mid trust score (51–75): steady-state throughput for a registered, moderately-trusted brand                                     | \~10,000/day                     |
| `verified` | High trust score (76–100): vetted-brand territory; the ceiling drops back materially when the brand was never externally vetted | up to \~200,000/day with vetting |

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):

| Day | Daily ceiling                                                  |
| --- | -------------------------------------------------------------- |
| 0   | 50                                                             |
| 3   | 123                                                            |
| 7   | 305                                                            |
| 10  | 756                                                            |
| 12  | 1,386                                                          |
| 14  | 3,000 (curve tops out; eligible to graduate to `warmed`)       |
| 15+ | 3,000 — the trust-tier phase cap is now the binding constraint |

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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/messages/senders/warmup" \
  -H "X-API-Key: dv_live_sk_..."
```

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:

|                         | Trust score                                                      | Reputation (health) score                                                                        |
| ----------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Question it answers** | How vetted is your brand's registration?                         | How well is this sender's traffic actually delivering?                                           |
| **Who computes it**     | The 10DLC registration ecosystem (The Campaign Registry vetting) | Orbit, from your own delivery receipts                                                           |
| **What moves it**       | Completing or upgrading brand registration / vetting             | Delivered, failed, and complaint-coded outcomes over a rolling 30-day window                     |
| **What it governs**     | The warming phase and its daily ceiling                          | Closed-loop feedback on the ramp, plus health/spam-likelihood surfaces and fleet aging decisions |

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](/numbers/health#reputation) and, for forward risk, the [spam-likelihood endpoint](/numbers/health#predictive-spam-likelihood-scoring--remediation-playbook).
* **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

* [Number health, warming, and carrier reputation tracking](/numbers/health) — the endpoint surface
* [Number warming guide](/guides/number-warming) — the ramp walkthrough, pacing, and quota-error handling
* [Brand identity and trust score](/concepts/brand-identity-trust-score) — the organization-level trust rollup, distinct from per-sender reputation
* [Send gating and quiet hours](/concepts/send-gating-and-quiet-hours) — the other volume guardrails warming composes with