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 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:

{
  "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.

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.

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.

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:

curl "https://api.orbit.devotel.io/api/v1/compliance/traceback" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

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 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:

Poll GET /traceback on a regular cadence (hourly is enough for a business-day window).
Alert when any open case reports sla.status: "due_soon" or sla.status: "breached", or sla.breached: true.
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 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.

STIR/SHAKEN attestation — the signing that creates the traceback obligation, attestation levels, and the controls you own.
Send Gates — the quiet-hours, DNC, RND, and RMD checks that run at send time.
Compliance Health Scores — the 0–100 risk scores for your organization, senders, and campaigns.
Compliance Posture Overview — how the individual compliance surfaces fit together.
API Reference → Compliance — full request/response schemas (regenerated from the live API).

Getting Started

Channels

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Changelog

ITG Traceback: Handling Requests for Originating Numbers

ITG Traceback Case Handling

Why attestation creates this obligation

Case lifecycle

Response-deadline SLA

Handling a traceback request, step by step

1. Log the inbound request

2. Acknowledge receipt

3. File your response

Dispositions

4. Review cases

Record-keeping surface only

Access control, audit, and storage

Watching the SLA

​ITG Traceback Case Handling

​Why attestation creates this obligation

​Case lifecycle

​Response-deadline SLA

​Handling a traceback request, step by step

​1. Log the inbound request

​2. Acknowledge receipt

​3. File your response

​Dispositions

​4. Review cases

​Record-keeping surface only

​Access control, audit, and storage

​Watching the SLA

​Related references

ITG Traceback Case Handling

Why attestation creates this obligation

Case lifecycle

Response-deadline SLA

Handling a traceback request, step by step

1. Log the inbound request

2. Acknowledge receipt

3. File your response

Dispositions

4. Review cases

Record-keeping surface only

Access control, audit, and storage

Watching the SLA

Related references