Quick answer: Devotel Orbit's emergency stop is an org-wide kill switch — one flag your organization owns that halts every outbound dispatch path (SMS, MMS, voice origination, dialer campaign activation) until you lift it. Blocked sends are rejected with 403 ORG_COMPLIANCE_EMERGENCY_STOP before provider dispatch, so no balance is debited for them. Only your owner or admin roles can read, activate, or deactivate it; developer and viewer roles get 403. This post covers when a narrower control isn't enough, the three incident patterns that justify the blunt instrument, the recovery runbook, and how to run it as a launch-day drill. The endpoint contracts live in the emergency stop docs; the full operator's guide is the Emergency Stop Runbook.
1. What a kill switch is — and when scrubbing isn't enough
Your compliance posture is built from scoped controls: quiet hours gate voice windows, DNC scrubs remove destinations, RND checks recycled numbers, rate overrides throttle a misbehaving channel. Each of them is a scalpel — it corrects one class of problem while the rest of the traffic flows.
A kill switch is the blunt instrument behind them. It exists for the moment when the cost of one more outbound send exceeds the cost of halting everything — when fixing the list, the channel, or the campaign is real-time work you cannot afford, and you need every dispatch path frozen while you do it.
The rule of thumb: use the scoped controls for posture; use the emergency stop for an incident. If you can name the problem (a bad list, a hot channel), pick the narrower tool and keep the rest of the operation running. If the problem is a moving target — you don't yet know which list, which channel, or which credential is compromised — freeze everything first, diagnose second.
2. The control itself
Three endpoints, all rooted at https://api.orbit.devotel.io/api/v1/compliance, all restricted to owner and admin roles — developer and viewer roles receive 403 on every one of them:
Check status — reads active plus activated_at, activated_by, and reason:
curl https://api.orbit.devotel.io/api/v1/compliance/emergency-stop \
-H "Authorization: Bearer $ORBIT_API_KEY"Activate — flips the switch ON. An optional reason (up to 500 characters) is stored on the flag and written to your audit log alongside the actor and timestamp, so a post-incident review can rebuild who stopped what, when, and why:
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/emergency-stop/activate \
-H "Authorization: Bearer $ORBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "reason": "Suspected list contamination — pausing all sends" }'Deactivate — lifts the halt and clears the stored state back to null:
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/emergency-stop/deactivate \
-H "Authorization: Bearer $ORBIT_API_KEY"Both write paths are rate-limited to 5 requests per minute, so a decisive click and a few retries get through, but the flag can't be thrashed. Every activation and deactivation lands in your audit log.
What the block actually does — and doesn't
While the switch is active, the send gate at the top of every outbound dispatch path rejects with 403 ORG_COMPLIANCE_EMERGENCY_STOP before the dispatcher selects a provider — so no provider call is made and no balance is debited for blocked sends. Blocked paths cover SMS, MMS, voice origination, dialer campaign activation, and the other messaging channels on the dispatch path (WhatsApp, RCS, Viber, Telegram, fax).
Two classes of traffic are deliberately not gated:
- Verify/OTP sends, so a contact can still receive a login code or
two-factor token while the switch is on.
- Email, which runs on a separate delivery path with its own
suppression list.
If your incident also requires freezing OTP or email, disable the relevant Verify profile or email sender in your settings. The emergency stop covers the dispatch path only — by design, so the panic button can't lock legitimate account recovery out alongside the marketing blast.
3. Three incident patterns that justify it
Suspected credential breach. A leaked API key or a sender behaving outside policy can push traffic you can't scope yet. Activate the stop while you rotate credentials and review the audit log — every outbound path goes quiet at once, including the ones you forget to list under pressure.
Runaway campaign. A misconfigured campaign or a content mistake dispatching at volume doesn't care which channel rate override you tweak; it will drain spend and complaint upside on any path left open. Freeze the dispatch layer, then fix the campaign definition before a single send resumes.
Litigator or carrier exposure in flight. A complaint spike, a carrier block notice, or a regulator inquiry mid-flight means every additional outbound message is potential evidence of a known problem. Halt everything while counsel or the carrier engagement runs; a partial throttle reads worse in review than a visible, deliberate freeze.
Each of these shares a shape: you cannot yet bound the problem to a list, a channel, or a contact, and the downside of one more send outweighs the downside of silence.
4. Narrower alternatives — pick the smallest sufficient tool
The emergency stop is intentionally the last resort. For bounded problems, the scoped controls carry less operational cost:
| Problem | Smallest sufficient tool |
|---|---|
| A bad or stale list | DNC scrub |
| One misbehaving channel | Channel rate overrides |
| Specific contacts to exclude | Opt-out suppression |
| Voice dialing windows | Send gates quiet hours |
| The problem can't be scoped to a list, channel, or contact | Emergency stop |
Reaching for the org-wide halt on a single bad list signals you don't trust your scoped controls — and it freezes compliant traffic with the non-compliant. Keep the kill switch reserved for the incidents its name implies.
5. Recovery runbook: deactivate, verify, re-queue
Lifting the halt is a three-step sequence you can practice before you need it:
- Resolve the root cause — rotate the leaked credential, halt the
runaway campaign, scrub the bad list. Deactivating before the cause is fixed just re-opens the incident.
- Deactivate —
POST /emergency-stop/deactivate(owner/admin)
clears the flag and is itself audit-logged.
- Verify, then re-queue —
GET /emergency-stopconfirms
active: false; only then re-dispatch queued or blocked sends.
Plan for enforcement (and lifting) within about 30 seconds of the write: the state is cached at the API layer to keep the per-send lookup off the message hot path. And if the state lookup ever fails, the gate treats the switch as OFF and logs — a transient read failure cannot black-hole all outbound traffic, and a reactivation POST after recovery restores enforcement.
6. Why drills matter
The first time an owner flips this switch should not be during a real incident. Add it to your launch checklist and your incident runbook: pick a low-traffic moment, have an owner/admin activate, verify a blocked send returns 403 ORG_COMPLIANCE_EMERGENCY_STOP, then deactivate and confirm the GET reads active: false. The Emergency Stop Runbook is referenced from the go-live checklist as a launch-day drill for exactly this reason — an operator who has only ever read about the switch will fumble the sequence under pressure.
Drills also exercise the smaller controls table above: run the DNC scrub, the rate override, and suppression on the same staging traffic you freeze, so the decision in step 1 of the table ("which list, which channel, which contact?") is a reflex, not a worksheet.
Frequently asked questions
Does the emergency stop cost us anything when it blocks a send?
No. Rejection happens before wallet hold and provider dispatch, so a blocked send is never debited from your balance. The block decision, channel, and message id are still written to your audit/event stream so you can measure the volume of traffic you froze.
Why don't Verify/OTP and email get gated?
OTP is how your contacts recover access — freezing it alongside a suspected breach would lock legitimate users out. Email runs on a separate delivery path with its own suppression handling. If an incident genuinely requires freezing those paths too, disable the Verify profile or email sender in settings; the emergency stop is scoped to the dispatch layer so it stays safe to press.
Can a developer rotate the emergency stop via API?
No. Both write endpoints, and the status read, are restricted to your owner and admin roles. Developer and viewer roles receive 403, which means a leaked developer-scoped key can't unilaterally halt — or resume — outbound traffic.
How long do blocked sends wait after deactivation?
Blocked sends are rejected, not queued, so re-dispatch is a client action: once GET /emergency-stop reads active: false, your application re-submits the holds it received as 403. The runbook sequence — resolve the cause, deactivate, verify, re-queue — is what keeps that lean.
See also:
the consolidated send-control surface the stop layers on top of
one of the scoped send-gate controls posture work belongs on
the narrower control for known-litigator exposure