Quick answer: Orbit rolls the four signals carriers actually act on — consent coverage, opt-out velocity, inbound STOP-reply rate, and carrier rejection rate — into a single 0–100 score, computed for your organization as a whole, for each sending number, and for each campaign. The surface is deliberately read-only: the score never blocks a send, suppresses a contact, or gates your traffic. It exists so you see the same pre-carrier warning signs a carrier sees, before the carrier decides to filter or throttle you. The full reference lives on the Compliance Health Scores docs page.
What the score reads
Carriers throttle the worst signal, not the weighted average — so the score does the same. Call GET /api/v1/compliance/health with your API key and you get back a score, a band (healthy 85–100, watch 70–84, at_risk 50–69, critical 0–49, or unknown when there is no traffic to evaluate), and a per-factor breakdown with a raw signal count behind every number:
| Factor | What it measures | Weight |
|---|---|---|
consent_coverage | Share of contacted recipients holding a current granted consent | 30% |
opt_out_velocity | New opt-outs per 1,000 messages sent | 15% |
stop_reply_rate | Inbound STOP replies as a share of messages sent | 25% |
carrier_rejection | Failed or undelivered messages as a share of sent | 30% |
Two rules keep the blend honest — both per the docs reference: a factor with insufficient data is excluded rather than scored as a false zero, and a single critical factor floors the band at at_risk no matter how strong the other three are. The organization endpoint aggregates all seven signal fields; the per-number (GET /compliance/health/numbers) and per-campaign (GET /compliance/health/campaigns) endpoints evaluate the factors their data supports and return the worst first, so one skim of either list answers "who is about to draw carrier attention."
A signal-by-signal recipe
Each factor maps to an operational lever. The score is how you find the flank; the lever below is how you move it back.
Consent coverage (30%). The feed is your consent ledger versus who you actually contacted: recipientsContacted against recipientsWithConsent. The lever that moves it is opt-in capture hygiene — close the gap in the Consent API flow by writing a consent record over POST /compliance/consent for the uncovered slice, with the current policy_template and a real consent_proof_url on each row. A 12,000-recipient list import with no accompanying consent capture is the classic way this factor slides from ≥95% into the 80–95% warning band.
Opt-out velocity (15%). This counts new opt-outs per 1,000 messages sent, healthy at ≤5 and acute above 20. The lever is suppression and list hygiene — the opt-out and suppression surface — combined with tightening targeting and cadence so the same recipients are not repeatedly hit past the point of tolerable annoyance.
STOP-reply rate (25%). Inbound STOP keywords as a share of sent volume, healthy at ≤0.5% and acute above 2%. The lever is the opt-out honor flow: your suppression must capture the inbound reply and exclude the number from future sends within the same window, before the recipient has to escalate to a carrier complaint.
Carrier rejections (30%). Failed or undelivered messages as a share of sent, healthy at ≤3% and acute above 10%. The lever is sender-registration and content-scope readiness — walk the 10DLC troubleshooting guide and the sender-ID gates for the number in question, and fix the registration or the filtered-content rule before raising volume.
The endpoint response carries a warnings[] array that names whichever of these is in warn or critical status, most-severe first, with a recommendation phrased in factor terms — the recipe above is what that recommendation points at.
The verification workflow
Reading the score ad hoc is the minimum. The numbers become an operating rhythm when three steps run on a loop.
First, poll on a fixed cadence. The compliance-health alerting runbook documents the canonical shape: hourly calls against /compliance/health/numbers and /compliance/health/campaigns, alarm on band transitions (a scope that moved from healthy to watch, or worse), not on absolute numbers. That keeps the alert queue to the handful of scopes that actually changed, while the alarm is still a targeting fix instead of an incident.
Second, threshold an internal alert. The org-score response tells you the band and the culprit factor, so a threshold rule like "any scope entering at_risk or critical pages the messaging owner" is a one-line polling script — the runbook ships a minimal Bash poller to copy. Scope the threshold to band transitions; a scope that has been in watch for six months is not news.
Third, fold the read into the quarterly posture review. The review treats consent-coverage drift, DSAR readiness, and evidence capture as one loop; the health score is the "read layer one for drift" step — check the org and top sender rows before a big rollout, and re-check after a fix lands to confirm it moved.
The read-only contract — and what it means for you
Every one of these endpoints is read-only advisory. A critical band does not pause your campaign, suppress a contact, or gate an API call — nothing in Orbit acts on the score without you. That is deliberate, and it is the tenant-owned framing the whole compliance surface holds: Orbit reports the posture; the threshold, the alarm, and the remediation are decisions you make and own. An alerting runbook you configure to page your own Slack channel is a tenant control, not an Orbit mandate.
That framing matters at audit time too. The trust-center evidence pack documents which control planes produce their own evidence and where each one lands, so when counsel or an auditor asks "who was watching carrier health," the answer names your own threshold rule and your own runbook — provable, rather than a shrug toward a default-open toggle.
Start reading it today
The score compounds the four signals on a rolling 1–90-day window (default 30). Load the dashboard panel under Settings → Compliance → Messaging Compliance Health for the three-scope view, or wire a two-call poll per the alerting runbook into your own alerting. Either way the fastest loop is the same one: worst-first, factor first, recommend second — then fix the signal, not the score.
Frequently asked questions
Do I have to do anything when a scope drops into `watch`? Not necessarily — the page is advisory and nothing blocks. watch is the early-warning band, and most tenants leave it at the monitor-and-tighten-targeting level; it becomes an actionable item when the factor is trending or a rollout is planned against that sender.
Why is my score `unknown` for a sender or a campaign? Every factor reported insufficient_data — typically because nothing was sent on that scope in the window you polled, or the window is too narrow for a brand new sender. That is a "no traffic to evaluate" state, not a failing grade.
Can I reset a bad score? No — and there is intentionally no reset knob. The score improves when the underlying signal improves, and the same window re-poll after your fix lands is the confirmation the fix worked. Big list imports and new campaigns get re-evaluated on the rolling window, so a genuinely cleaner posture moves the number within days.
Which endpoint should a poller actually call? Both list endpoints, ordered worst-first: /compliance/health/numbers for per-sender flanks and /compliance/health/campaigns for per-campaign ones. The org rollup (/compliance/health) is the summary a human glances at; the lists are where new drifts actually appear.
Is the cadence in the alerting runbook mandatory? No — it is a documented operator playbook, and the hourly-poll/band-transition pattern is a recommendation, not a platform-enforced rule. Your alarm thresholds, your channel, your cadence.