Skip to main content
The Compliance hub under Settings → Compliance is your day-to-day console for messaging posture: a status dashboard on the Overview tab, and task tabs for consent, privacy, retention, evidence, messaging compliance, security, and legal policies. This page answers the questions operators ask most about the hub itself. For the full list of quick links and role gates, use the Compliance hub route map; for the scoring API in detail, see Compliance health.

​
How is the hub organized?

The hub renders one task tab at a time: Overview, Consent & Preferences, Privacy & Data Rights, Retention, Audit & Evidence, Messaging Compliance, Security & Verification, and Legal Policies. The tab strip is your “where am I” cue, and the Overview tab is the status dashboard, opening on the Messaging Compliance Health panel. Everything else groups by the decision it supports: consent and opt-out tooling under Consent & Preferences, retention and residency under Retention, evidence and audit exports under Audit & Evidence, and so on. Deep links keep working: a URL such as /settings/compliance#ten-dlc opens the tab that owns the control and scrolls to it, and switching tabs preserves any unsaved draft you left on another tab.

​
What does the Messaging Compliance Health panel show?

A 0–100 health score for your organization with a risk band (Healthy, Watch, At risk, Critical, or No data), plus one tile per scoring factor: consent coverage, opt-out velocity, STOP-reply rate, and carrier rejections. Each tile carries a status dot, the factor’s current value, and a one-line read of what it means. When a factor crosses a carrier threshold, the panel adds a warning with a recommended corrective action. A window selector scores the last 7, 30, or 90 days. Below the rollup, a “By sender” table ranks every sending identity worst score first, and a “By campaign” table does the same for campaign traffic, so the senders and campaigns to look at first are always at the top. Empty tables simply mean no outbound traffic in the selected window yet.

​
Which endpoints feed the panel?

Three read-only endpoints: All three accept window_days (1–90, default 30); the list endpoints also accept limit (up to 200, default 50). The scores are computed from your own traffic: sends, deliveries, carrier rejections, STOP replies, opt-outs, and consent records in the selected window. The console re-fetches the scores every couple of minutes, so after you change a control or correct a send practice, allow one refresh before you re-read the panel. A scope with too little traffic in the window renders “No data” instead of a number, and its factors read “Not enough data”. That is not a judgment on your posture; the factor simply does not count toward the rollup. Widening the window to 90 days usually gives thin senders enough traffic to score.

​
What do the per-sender rows and their flags mean?

One row per sending identity, worst score first. The Type column names the identity: long code, toll-free, short code, or alphanumeric Sender ID. Each row shows the score, the risk band, and messages sent in the window; the band is the flag you act on. Traffic whose sending identity can no longer be resolved (a deleted or never-recorded sender) appears as an “Unknown sender” row instead of a blank one, so that traffic stays investigable. Selecting a row opens the sender detail sheet.

​
What does the sender detail sheet add?

The investigation path a summary row cannot carry: sent, delivered, and failed/rejected counts for the window; the factor-by-factor calculation of the sender’s score; the prioritized corrective actions the scoring API returns for that sender; and two links into the message logs, one scoped to failed/rejected messages and one to all traffic from the sender, where the per-message carrier and provider error codes live.

​
Does a low score block my sends?

No. The panel and the scoring API are read-only; they warn you before carriers throttle your traffic, they do not gate it. Compliance posture is your tenant’s responsibility: every control you configure in the hub (quiet hours, opt-out lists, consent requirements, country rules) is your decision and ships defaulted off, so nothing is enforced until you turn it on. Nothing in the hub sends a message or places a call on your behalf. That is the opposite of a hidden block. When you do switch a control on, a sender outside your posture is rejected by a control you chose, and the troubleshooting guides name the error code and the console that owns the fix.

​
Does the platform enforce anything regardless of my settings?

One thing: the US federal TCPA voice dialing window. It is the single platform-applied hard guard. It accepts no tenant toggle and fails closed; a call whose recipient timezone cannot be resolved is not placed. See Quiet-hours and dialing windows. Every other control in the hub is tenant-owned.

​
Where do opt-out and sender work happen outside Settings?

Recipients opt out by replying STOP (keyword handling checks your suppression lists at send time) or through your public preference center. Sender ID registration lives under Audience → Senders, not in the hub; see Sender ID registration. Compliance Profiles are assembled in Settings but attach to audiences, campaigns, and numbers, so the posture travels with the traffic.

​
Where do the breach register and DSAR live?

The Breach Incidents console in the hub is your Article 33/34 register; the Compliance Binder collects the supporting evidence, and breach recording explains the register’s fields. DSAR has two surfaces: the team console in Settings that queues and fulfills requests, and a public portal where the data subject files and verifies the request before any export runs. See DSAR. Both consoles are audited: opening, creating, and changing a record writes your user and the action into the audit ledger, so the evidence your binder collects also covers who maintained it. Because of that, owners and admins are the default roles for these consoles, with the day-to-day send-setup consoles the exception.

​
What if the health panel shows an error?

If the panel cannot reach the scoring API, it shows a single warning with a Retry button that re-queries all three endpoints at once. An error state never affects your sends, because the panel is read-only; it only delays your view of the score. If retries keep failing, the API itself is the surface to check on the status page, not the hub.

​
Who can open the hub and its consoles?

Organization owners and admins see the hub entry; other roles do not. Inside the hub, a quick link is hidden from a role that cannot use it rather than shown and rejected on open. The four day-to-day send-setup consoles (Country Regulatory Rules, Opt-Out Lists, Compliance Profiles, Compliance Documents) are open to every role. The per-role table lives in the route map.

​
See also