> ## 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. # ITG Traceback: Handling Requests for Originating Numbers > Log, acknowledge, and respond to Industry Traceback Group requests implicating your originating numbers — the case lifecycle, the 24-hour response SLA, and the dispositions you file. # ITG Traceback Case Handling Signing your outbound US voice traffic with STIR/SHAKEN attestation carries a downstream obligation: when one of your originating numbers is implicated in a robocall complaint, the Industry Traceback Group (ITG) can send you a **traceback request** asking you to identify the source of the call, and you are expected to respond, typically within about 24 hours (one business day). Orbit provides the case-management surface for that obligation: a place to log each inbound ITG request, acknowledge it, file your disposition, and watch the response deadline. Every control on this page is **tenant-owned** — you log the request, you decide the disposition, you file it with the ITG. All endpoints below are rooted at `https://api.orbit.devotel.io/api/v1/compliance`. Traceback response is part of FCC robocall mitigation under the TRACED Act (the ITG is operated by USTelecom under the FCC's framework). Consistently ignoring traceback requests is itself a compliance red flag that can escalate to enforcement and carrier de-peering. This page is not legal advice — confirm your traceback obligations and deadlines with counsel. *** ## Why attestation creates this obligation STIR/SHAKEN is the caller-ID authentication framework the FCC mandates for US voice traffic. Every outbound call you place through Orbit is assigned an attestation level (A, B, or C) at signing — see [STIR/SHAKEN attestation](/channels/voice/stir-shaken) for what the levels mean and how Orbit reaches them. Because your signed traffic can be attributed back to you, downstream providers and the ITG (ATIS/FCC traceback framework) can ask you where an implicated call came from. Answering those requests promptly and keeping a record of what you found is part of the robocall mitigation duties that come with originating signed traffic. ## Case lifecycle Each traceback case moves through four states: | From \ To | `acknowledged` | `responded` | `closed` | | ------------------- | -------------- | ----------- | -------- | | `received` | Yes | Yes | Yes | | `acknowledged` | — | Yes | Yes | | `responded` | — | — | Yes | | `closed` (terminal) | — | — | — | * `received` — the ITG request is logged, not yet worked. * `acknowledged` — you have confirmed receipt to the ITG. * `responded` — you have filed your disposition with the ITG. * `closed` — the case is settled (terminal; no further transitions). An invalid transition (for example, acknowledging a `closed` case, or responding twice) returns a `409` with `TRACEBACK_INVALID_TRANSITION`. ## Response-deadline SLA Every case carries a response-deadline clock. The default window is **24 hours** from `received_at`, which is the conservative encoding of the ITG's one-business-day expectation. You can set a tighter or looser window per case with `sla_hours` (up to 720) when the ITG states a different deadline. You never query SLA state directly — every `GET` on the traceback surface annotates each case with a **live verdict** computed at read time: ```json theme={null} { "sla": { "due_at": "2026-08-27T09:15:00.000Z", "status": "due_soon", "hours_remaining": 3, "breached": false, "reason": "The ITG response window closes soon; respond to avoid breaching the traceback SLA." } } ``` | `status` | Meaning | | ---------- | ------------------------------------------------------------------------------ | | `on_track` | Open, comfortably before the deadline. | | `due_soon` | Open, within 4 hours of the deadline. | | `met` | Responded on or before the deadline. | | `breached` | Deadline passed with no response, or the response was late (`breached: true`). | | `unknown` | The received-at timestamp is unparseable, so no deadline can be computed. | ## Handling a traceback request, step by step All writes below require the **owner or admin** role; reads are open to any authenticated member. ### 1. Log the inbound request When an ITG traceback request arrives, log it to start the clock. Provide the ITG's reference, the implicated originating number (E.164), and optionally a description of the implicated campaign, the attestation level asserted on that traffic, and a custom deadline. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "traceback_ref": "ITG-2026-11843", "source_number": "+14155550101", "campaign_description": "Outbound renewal-notice campaign flagged in a robocall complaint", "attestation": "A", "notes": "Received via the ITG portal on 2026-08-26" }' ``` The case is created in `received` state and the 24-hour deadline starts from the log time. Keep the `id` from the response for the next steps. ### 2. Acknowledge receipt Confirm to the ITG that the request is being worked. This moves the case to `acknowledged` and is optional — you may respond directly from `received`. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4/acknowledge" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{"notes": "Acknowledged to the ITG under their reference ITG-2026-11843"}' ``` ### 3. File your response Once you have investigated, record the disposition. This stops the response-deadline clock and, with `"close": true`, closes the case in the same call. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4/respond" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "disposition": "source_identified", "notes": "Traffic traced to sub-account supplier-7; source identification supplied to the ITG.", "close": true }' ``` ### Dispositions Choose the disposition that answers "what did you do about the implicated traffic?": | Disposition | Meaning | | --------------------- | ----------------------------------------------------------------------- | | `source_identified` | You identified the upstream/customer source and supplied it to the ITG. | | `customer_notified` | You warned the implicated customer. | | `customer_terminated` | You disconnected the implicated customer or campaign. | | `number_disabled` | You disabled the implicated originating number. | | `not_originated_here` | The traffic did not originate on your account. | | `no_action` | You reviewed and took no action (explain in `notes`). | ### 4. Review cases List every case with its live SLA verdict, or fetch one case by id: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/traceback" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` Cases list newest-request first, so any open case approaching its deadline is visible from the first page. *** ## Record-keeping surface only The traceback surface **receives, tracks, and records** — nothing else. Logging a case, acknowledging it, and filing a response persist state; they never place a call, send a message, or contact the ITG or the implicated customer on your behalf. Filing a response records the disposition you chose; delivering that response to the ITG (their portal or channel) and any downstream customer notification remain your actions, outside this surface. This boundary is deliberate: compliance case-tracking must never become an outbound path. ## Access control, audit, and storage * **Roles.** Writes (`POST /traceback`, `/acknowledge`, `/respond`) require the **owner or admin** role, mirroring the rest of the compliance write surface. Reads are available to any authenticated organization member. * **Audit trail.** Every state change writes a durable [audit log](/compliance/consent-management) entry — `compliance.traceback.received`, `compliance.traceback.acknowledged`, and `compliance.traceback.responded` — with the acting user, the ITG reference, and (on a response) the disposition and whether the deadline was met. The implicated number is masked in audit details. * **Storage.** Cases are stored on your organization's settings as a server-generated, per-case key, so two teammates working different cases (or other settings) concurrently never overwrite one another. ## Watching the SLA Build the list endpoint into your ops loop so a breach is never a surprise: 1. Poll `GET /traceback` on a regular cadence (hourly is enough for a business-day window). 2. Alert when any open case reports `sla.status: "due_soon"` or `sla.status: "breached"`, or `sla.breached: true`. 3. Page the compliance owner when a breach appears — an overdue traceback is the signal carriers and the FCC weight most heavily. The same `GET`-time verdict pattern that powers the [Compliance Health Scores](/compliance/compliance-health) surface applies here: scores warn you before carrier throttling, and traceback verdicts warn you before an escalation — treat both as early-warning feeds into your compliance posture. *** ## Related references * [STIR/SHAKEN attestation](/channels/voice/stir-shaken) — the signing that creates the traceback obligation, attestation levels, and the controls you own. * [Send Gates](/compliance/send-gates) — the quiet-hours, DNC, RND, and RMD checks that run at send time. * [Compliance Health Scores](/compliance/compliance-health) — the 0–100 risk scores for your organization, senders, and campaigns. * [Compliance Posture Overview](/compliance/posture-overview) — how the individual compliance surfaces fit together. * [API Reference → Compliance](/api-reference/endpoints/compliance) — full request/response schemas (regenerated from the live API).