> ## 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. # CALEA Lawful-Intercept Provisioning > How to log, authorize, activate, suspend, and audit lawful-intercept orders against court-authorized warrants — a provisioning and audit-trail surface only; Orbit never performs capture or media tapping. # CALEA Lawful-Intercept Provisioning Orbit provides **provisioning and an auditable workflow only**. This surface does not capture calls, tap media, wire a carrier, or hand anything to a law-enforcement agency. Activating an order records that the intercept is authorized and running within its warrant window — nothing more. Actual capture and delivery to a law-enforcement collection function is a softswitch / mediation concern, out of scope for this page. This page is not legal advice; confirm your lawful- intercept obligations with qualified counsel. ## What CALEA is The Communications Assistance for Law Enforcement Act (CALEA, 47 U.S.C. §§ 1001–1010) obligates carriers that route voice and SMS to be able, on a court-authorized warrant, to provision an intercept against an identified target. Orbit routes carrier-grade voice and SMS through the Devotel wholesale softswitch, so your organization may be served with lawful-intercept warrants and must be able to answer them. Two capture scopes exist: * **Pen register / trap-and-trace** — call-identifying information only (dialled or received digits, timestamps, routing, signalling). No call content. * **Title III intercept** — call-identifying information plus call content (the audio of the call). The warrant names the scope it authorizes; only a Title III order permits content capture. ## Why the register exists A warrant can arrive at any time, from any authority, naming any of your numbers. When it does, you need a single register that answers three questions with evidence: *what was requested of us, who inside the organization authorized and ran it, and was it ever live outside its authorization window?* The intercept order register answers those questions. Each order records the authorizing warrant metadata — court order reference, issuing authority, requesting law-enforcement agency — the capture scope, and the authorization window, then moves through a guarded lifecycle with only valid forward transitions. Every create and every status change writes an audit-log entry, and every read returns a live verdict on whether the order is inside its authorized window. All write endpoints are gated behind the **owner** or **admin** role; reads are authenticated and tenant-scoped. Order records are stored per-organization; one organization can never see another's orders. ## Intercept order lifecycle An order moves through exactly one path forward: `requested` → `authorized` → `active` → `suspended` → `terminated` * `requested` — the warrant has been logged; internal legal review is pending. * `authorized` — legal review confirmed the warrant; the order is ready to activate. * `active` — the intercept is provisioned and recorded as running, inside its warrant window. * `suspended` — temporarily paused; it can resume to `active`. * `terminated` — torn down. Terminal; the order can no longer change. Allowed transitions: | From | To | | ------------ | -------------------------- | | `requested` | `authorized`, `terminated` | | `authorized` | `active`, `terminated` | | `active` | `suspended`, `terminated` | | `suspended` | `active`, `terminated` | | `terminated` | (none — terminal) | Anything else returns `409`. You cannot skip a state (for example, activate from `requested` without an authorization step) and you cannot mutate a terminated order. ### Log an intercept order ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "warrant_ref": "2026-CV-11842, N.D. Cal.", "surveillance_type": "title_iii", "target_number": "+14155551234", "authorized_from": "2026-08-24T00:00:00.000Z", "authorized_until": "2026-09-23T00:00:00.000Z", "issuing_authority": "U.S. District Court, N.D. Cal.", "law_enforcement_agency": "Federal Bureau of Investigation", "notes": "30-day Title III order; renew before lapse." }' ``` Required body fields: | Field | Rule | | ------------------- | ---------------------------------------------------------------------- | | `warrant_ref` | 1–200 chars. Court order or docket reference, as supplied. | | `surveillance_type` | One of `pen_register`, `trap_and_trace`, `title_iii`. | | `target_number` | E.164 format, e.g. `+14155551234`. | | `authorized_from` | ISO-8601 date-time — the warrant start. | | `authorized_until` | ISO-8601 date-time — the warrant end. Must be after `authorized_from`. | Optional: `issuing_authority`, `law_enforcement_agency`, `notes` (each string, bounded length). A bad payload returns `422 VALIDATION_ERROR` with the failing fields. A `201` response returns the new order — the server derives a `captures_content` flag from the scope (`true` only for `title_iii`), stamps the lifecycle timestamps, and attaches a live `warrant_window` verdict: ```json theme={null} { "data": { "id": "lawint_3f9c2e1b8a4d4c7e9f1a2b3c4d5e6f70", "warrant_ref": "2026-CV-11842, N.D. Cal.", "surveillance_type": "title_iii", "captures_content": true, "target_number": "+14155551234", "issuing_authority": "U.S. District Court, N.D. Cal.", "law_enforcement_agency": "Federal Bureau of Investigation", "status": "requested", "authorized_from": "2026-08-24T00:00:00.000Z", "authorized_until": "2026-09-23T00:00:00.000Z", "requested_at": "2026-08-24T17:41:12.403Z", "authorized_at": null, "activated_at": null, "suspended_at": null, "terminated_at": null, "termination_reason": null, "notes": "30-day Title III order; renew before lapse.", "updated_at": "2026-08-24T17:41:12.403Z", "warrant_window": { "status": "in_window", "expired": false, "in_window": true, "hours_remaining": 719, "reason": "The intercept is within its authorized warrant window." } }, "meta": { "request_id": "req_…", "timestamp": "2026-08-24T17:41:12.403Z" } } ``` ### Authorize the warrant Legal review confirms the warrant is valid; this records that decision: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts/lawint_3f9c…/authorize \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "notes": "Warrant verified with issuing court clerk." }' ``` Only valid from `requested`; otherwise `409`. `notes` is optional (≤ 2000 chars). Returns the order with `status: "authorized"` and `authorized_at` stamped. ### Activate the intercept Marks the intercept as provisioned and running — and checks the warrant window first: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts/lawint_3f9c…/activate \ -H "X-API-Key: dv_live_sk_..." ``` Only valid from `authorized` or `suspended`. Activation **refuses an expired or unevaluable warrant window** (`409`) so an intercept can never be marked running outside its authorization. A valid activation returns the order with `status: "active"` and `activated_at` stamped (`activated_at` is set on the first activation and kept through later suspend/resume cycles). ### Suspend an intercept Pause an active order; it can resume later: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts/lawint_3f9c…/suspend \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "notes": "Paused pending court clarification of scope." }' ``` Only valid from `active`; otherwise `409`. Returns the order with `status: "suspended"` and `suspended_at` stamped. ### Terminate the order Tear the order down with a recorded reason. Terminal: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts/lawint_3f9c…/terminate \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "termination_reason": "completed", "notes": "Investigation concluded." }' ``` `termination_reason` is one of `completed` (investigation concluded), `warrant_expired`, `warrant_revoked` (court quashed the order), `rejected` (internal legal review rejected the warrant), or `withdrawn` (the requesting agency withdrew). Valid from any non-terminal state. Returns the order with `status: "terminated"`, `terminated_at` stamped, and `termination_reason` set. ### List and read orders ```bash theme={null} curl https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts \ -H "X-API-Key: dv_live_sk_..." curl https://api.orbit.devotel.io/api/v1/compliance/calea/intercepts/lawint_3f9c… \ -H "X-API-Key: dv_live_sk_..." ``` * `GET /compliance/calea/intercepts` — every order for your organization, newest first, as `{ data: { orders: [...], total: n } }`. * `GET /compliance/calea/intercepts/{id}` — one order, or `404 CALEA_INTERCEPT_NOT_FOUND` if the id does not belong to your organization. Every order on both endpoints carries a **live** `warrant_window` verdict, recomputed at request time. Error responses use the standard envelope: `422 VALIDATION_ERROR` on a bad payload, `404 CALEA_INTERCEPT_NOT_FOUND` on an unknown id, `409 CALEA_INTERCEPT_INVALID_TRANSITION` on an out-of-order lifecycle move. ## Warrant-window maths A Title III intercept typically carries a bounded authorization — commonly a 30-day window that must be renewed by a fresh court order before it lapses. The register evaluates that window on every read so you can see at a glance whether a given order may still be running. `warrant_window.status` values: | Status | Meaning | | --------------- | ---------------------------------------------------------------------------------------------------- | | `pending` | `authorized_from` is in the future; capture is not yet authorized. | | `in_window` | Now is inside `[authorized_from, authorized_until]`. | | `expiring_soon` | In-window, with 72 hours or fewer left — renew the court order to avoid an unauthorized-capture gap. | | `expired` | Past `authorized_until`; any capture must have stopped. Terminate or renew. | | `unknown` | A timestamp is missing or unparseable; the window cannot be evaluated. | The verdict also returns `expired` and `in_window` booleans, `hours_remaining` until the window closes (negative once expired — `null` when the window cannot be evaluated), and a human-readable `reason` for the audit trail. Two requests a minute apart can report different verdicts on the same order — the verdict is computed live, not stored. ## Provisioning and audit only — the hard boundary Hold this boundary whenever you operate the register: * Activating an order **records** that the intercept is authorized and running within its window. Orbit does not capture calls, does not tap media, does not place a call, does not send a message, and does not wire a carrier. * Any actual capture and delivery to a law-enforcement collection function happens in the softswitch / mediation layer, outside this surface. * What Orbit does guarantee on this surface: records are organization-scoped and write-access is restricted to owner/admin; lifecycle transitions are guarded (you end with evidence of exactly which states the order passed through); activation is refused once the warrant window is closed; and every state change is written to the audit log with the warrant reference, the acting user, and the time. When a warrant expires, terminate the order with reason `warrant_expired`. When a court renews it, log a **new** order for the renewed window rather than stretching the old one — the warrant reference and window must match the document in force, and a fresh order keeps that chain of evidence clean.