Quick answer: The Robocall Mitigation Database (RMD) is the FCC's public registry of every US voice service provider. Under 47 CFR § 64.6305, a provider that originates calls must file its STIR/SHAKEN implementation level and, if it has not fully deployed STIR/SHAKEN, a description of the robocall-mitigation program it runs. Terminating carriers are required to refuse traffic from providers whose filings are missing or deficient. Devotel Orbit is the ledger for that obligation: it records the filing state from draft to active, computes the recertification countdown, and can enforce a not-current filing at call time. The filing itself, and every lifecycle judgment along the way, stays with you.
Who has to file, and what a filing contains
The obligation sits in 47 CFR § 64.6305: every voice service provider that originates calls on US networks must be in the database. The filing declares two things:
- Your STIR/SHAKEN implementation level: full, partial, or none.
- Your robocall-mitigation program. Required whenever the declared level is not full, it describes the concrete steps you take to keep illegal robocalls off your originating traffic.
The enforcement teeth are downstream-facing: terminating carriers must refuse traffic from providers that are absent from the database or whose filings are flagged deficient. A missing or stale filing directly causes your outbound calls to be blocked or labeled downstream, so "first file, keep it current" is not bureaucratic overhead. It is how your traffic keeps its path.
The filing lifecycle, from draft to recertification
An RMD filing is not a register-once artifact. It moves through states, and each state answers a different operational question:
- draft: the filing is being prepared; nothing submitted yet.
- submitted: filed with the FCC RMD portal, awaiting publication.
- active: published in the RMD; the recertification clock is running.
- remediation_required: a terminating carrier or the FCC flagged a deficiency to correct.
- withdrawn: filing withdrawn or superseded. Not terminal, since a withdrawn filing re-opens to
draftwhen you re-file.
Two clocks ride on the active state. The FCC expects a filing updated within 10 business days of any change, and most operators re-attest annually. Orbit computes the review deadline from your certified date plus your chosen interval (365 days by default, settable up to 3650) and reads it back as a live verdict on every fetch:
{
"registration": {
"state": "active",
"stir_shaken_status": "complete",
"certified_at": "2026-03-12T14:08:00Z"
},
"recertification": {
"status": "due_soon",
"due_at": "2027-03-12T14:08:00Z",
"days_remaining": 27,
"overdue": false
},
"enforcement": "warn",
"update_window_business_days": 10
}The verdict is one of current, due_soon (within 30 days of the review date), overdue, not_certified, or withdrawn. That read turns "is our filing about to lapse?" from a calendar task into an API call.
What Orbit records, and what stays with the operator
The split is deliberate:
- Orbit records the full filing state machine (
draft→submitted→active→remediation_required→withdrawn), the recertification countdown above, the FCC filing reference and deficiency notes you attach, and the enforcement posture you choose for your own origination. - The operator owns filing with the FCC portal directly, deciding the declared STIR/SHAKEN level, writing the robocall-mitigation description, and answering any deficiency the FCC or a terminating carrier raises.
Nothing in the platform files with the FCC for you. The record, the clock, and the guard exist so the obligation you own is never invisible, not to move it onto the platform.
Where the record lives: the dashboard and the API
The dashboard surface is Settings → Compliance → RMD, and it drives the same endpoints an integration can call directly, all rooted at https://api.orbit.devotel.io/api/v1/compliance:
| Endpoint | What it does |
|---|---|
POST /compliance/rmd | Create or update the draft registration (upsert). Allowed only while the filing is draft or withdrawn. |
GET /compliance/rmd | Fetch the registration, the live recertification verdict, and the current enforcement mode in one call. |
POST /compliance/rmd/submit | draft → submitted, recording the FCC filing reference. |
POST /compliance/rmd/certify | submitted → active; starts the recertification clock. |
POST /compliance/rmd/remediation | active → remediation_required, recording the flagged deficiency. |
POST /compliance/rmd/resolve | remediation_required → active; restarts the clock. |
POST /compliance/rmd/withdraw | Any state → withdrawn. |
Writes require the owner or admin role; the read is open to any authenticated member. An out-of-order transition returns 409 RMD_INVALID_TRANSITION, and a submit with missing required pieces returns 409 RMD_INCOMPLETE with a details array naming each blocker. The most common blocker is the mitigation plan, which is mandatory unless the declared STIR/SHAKEN level is complete.
The opt-in origination guard
Tracking answers "what is our RMD state?" A second, opt-in layer answers "should we originate right now, given that state?" The voice pre-origination guard checks the filing of the originating organization, not the recipient, before an outbound call is placed. It runs in one of three modes you set via PUT /compliance/rmd/enforcement:
- off: the default. The guard is inert; nothing is flagged or blocked.
- warn: a not-current filing is logged and flagged in the trace, but the call proceeds. Use this as a dry run before committing to enforce.
- enforce: a not-current filing blocks origination with a
403 RMD_NOT_CURRENTerror naming the reason: no filing, not active, an open deficiency, or a past-due recertification.
Two behaviors are deliberate. The guard fails open: if the settings read errors at call time, the call proceeds, because a lookup blip must never break dialing. The recipient-facing gates (DNC scrub, quiet hours) are the fail-closed backstop; this guard is about your own filing. And preview paths never throw: dry-run origination evaluates the same verdict and surfaces it as a flag, so tooling can answer "would this call be held under enforce?" without blocking.
Whether to enable the guard is a posture decision your organization makes. The default is off, and warn exists so you can measure the impact before you enforce.
Tenant-owned by design, explainer not legal advice
Orbit is the ledger, not the filing party. It registers the record, syncs the state, keeps the recertification countdown, and attaches the opt-in origination guard. The obligation, and every lifecycle call above, stays with your organization. And this page is an explainer, not legal advice: the duty to file, what the filing must contain, and how current it must stay depend on your network and traffic, so confirm those answers with qualified counsel.
The endpoint-by-endpoint walkthrough with request shapes, the transition table, and error codes lives in the RMD filing lifecycle docs.