> ## 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: gestión de solicitudes sobre sus números de origen

> Registre, acuse y responda a las solicitudes del Industry Traceback Group que implican sus números de origen — el ciclo de vida del caso, el SLA de respuesta de 24 horas y las disposiciones que usted presenta.

# Gestión de casos de ITG Traceback

Firmar su tráfico de voz saliente de EE. UU. con attestación STIR/SHAKEN conlleva una
obligación derivada: cuando uno de sus números de origen queda implicado en una
reclamación por robocalls, el Industry Traceback Group (ITG) puede enviarle una
**solicitud de traceback** pidiéndole que identifique el origen de la llamada, y se
espera que usted responda, normalmente en unas 24 horas (un día laborable).

Orbit proporciona la superficie de gestión de casos para esa obligación: un lugar para registrar
cada solicitud ITG entrante, acusarla recibo, presentar su disposición y vigilar el
plazo de respuesta. Cada control de esta página es **propiedad del tenant** — usted registra la
solicitud, usted decide la disposición, usted la presenta al ITG.

Todos los endpoints siguientes tienen la raíz
`https://api.orbit.devotel.io/api/v1/compliance`.

<Warning>
  La respuesta a traceback es parte de la mitigación de robocalls de la FCC bajo la Ley TRACED
  (el ITG es operado por USTelecom dentro del marco de la FCC). Ignorar
  de forma constante las solicitudes de traceback es por sí mismo una señal de alarma de cumplimiento que puede
  escalar a aplicación y desvinculación por los operadores. Esta página no es asesoramiento
  legal — confirme sus obligaciones y plazos de traceback con un abogado.
</Warning>

***

## Por qué la attestación crea esta obligación

STIR/SHAKEN es el marco de autenticación de identificador de llamada que la FCC exige para el
tráfico de voz de EE. UU. A cada llamada saliente que usted realiza a través de Orbit se le asigna un
nivel de attestación (A, B o C) en la firma — consulte
[Attestación STIR/SHAKEN](/channels/voice/stir-shaken) para el significado de los niveles
y cómo Orbit los alcanza. Debido a que su tráfico firmado puede atribuirse
a usted, los proveedores downstream y el ITG (marco de traceback ATIS/FCC)
pueden preguntarle de dónde vino una llamada implicada. Responder a esas solicitudes
con prontitud y conservar un registro de lo que encontró es parte de los deberes de
mitigación de robocalls que vienen con originar tráfico firmado.

## Ciclo de vida del caso

Cada caso de traceback atraviesa cuatro estados:

| Desde \ Hasta       | `acknowledged` | `responded` | `closed` |
| ------------------- | -------------- | ----------- | -------- |
| `received`          | Sí             | Sí          | Sí       |
| `acknowledged`      | —              | Sí          | Sí       |
| `responded`         | —              | —           | Sí       |
| `closed` (terminal) | —              | —           | —        |

* `received` — la solicitud ITG queda registrada, aún no trabajada.
* `acknowledged` — usted confirmó la recepción ante el ITG.
* `responded` — usted presentó su disposición ante el ITG.
* `closed` — el caso está resuelto (terminal; sin más transiciones).

Una transición inválida (por ejemplo, acusar recibo de un caso `closed`, o
responder dos veces) devuelve un `409` con `TRACEBACK_INVALID_TRANSITION`.

## SLA de plazo de respuesta

Cada caso lleva un reloj de plazo de respuesta. La ventana predeterminada es de **24
horas** desde `received_at`, que es la codificación conservadora de la expectativa ITG de
un día laborable. Puede establecer una ventana más ajustada o más holgada por caso
con `sla_hours` (hasta 720) cuando el ITG indica un plazo diferente.

Nunca consulta el estado del SLA directamente — cada `GET` sobre la superficie de traceback
anota cada caso con un **veredicto en vivo** calculado en el momento de la lectura:

```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`   | Significado                                                                                  |
| ---------- | -------------------------------------------------------------------------------------------- |
| `on_track` | Abierto, cómodamente antes del plazo.                                                        |
| `due_soon` | Abierto, a menos de 4 horas del plazo.                                                       |
| `met`      | Respondido en o antes del plazo.                                                             |
| `breached` | Plazo vencido sin respuesta, o la respuesta fue tardía (`breached: true`).                   |
| `unknown`  | La marca de tiempo de recepción no se puede analizar, por lo que no se puede calcular plazo. |

## Gestión de una solicitud de traceback, paso a paso

Todas las escrituras siguientes requieren el rol de **owner o admin**; las lecturas están abiertas a cualquier
miembro autenticado.

### 1. Registre la solicitud entrante

Cuando llega una solicitud de traceback del ITG, regístrela para iniciar el reloj. Proporcione la
referencia del ITG, el número de origen implicado (E.164) y, opcionalmente, una
descripción de la campaña implicada, el nivel de attestación declarado en ese
tráfico, y un plazo personalizado.

```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"
  }'
```

El caso se crea en estado `received` y el plazo de 24 horas comienza desde
la hora del registro. Conserve el `id` de la respuesta para los pasos siguientes.

### 2. Acuse recibo

Confirme al ITG que la solicitud se está trabajando. Esto mueve el caso a
`acknowledged` y es opcional — puede responder directamente desde `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. Presente su respuesta

Una vez investigado, registre la disposición. Esto detiene el
reloj del plazo de respuesta y, con `"close": true`, cierra el caso en la misma
llamada.

```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
  }'
```

### Disposiciones

Elija la disposición que responde a "¿qué hizo usted con el tráfico implicado?":

| Disposición           | Significado                                                         |
| --------------------- | ------------------------------------------------------------------- |
| `source_identified`   | Usted identificó el origen upstream/cliente y lo suministró al ITG. |
| `customer_notified`   | Usted advirtió al cliente implicado.                                |
| `customer_terminated` | Usted desconectó al cliente o campaña implicado.                    |
| `number_disabled`     | Usted deshabilitó el número de origen implicado.                    |
| `not_originated_here` | El tráfico no se originó en su cuenta.                              |
| `no_action`           | Usted revisó y no tomó acción (explique en `notes`).                |

### 4. Revise los casos

Liste todos los casos con su veredicto SLA en vivo, o recupere un caso por 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"
```

Los casos se listan con la solicitud más reciente primero, por lo que cualquier caso abierto
que se acerque a su plazo es visible desde la primera página.

***

## Superficie de solo registro

La superficie de traceback **recibe, rastrea y registra** — nada más.
Registrar un caso, acusarlo recibo y presentar una respuesta persisten estado; nunca
realizan una llamada, envían un mensaje ni contactan al ITG o al cliente implicado
en su nombre. Presentar una respuesta registra la disposición que usted eligió;
entregar esa respuesta al ITG (su portal o canal) y cualquier
notificación al cliente downstream siguen siendo acciones suyas, fuera de esta superficie.
Este límite es deliberado: el seguimiento de casos de cumplimiento nunca debe convertirse en
una ruta saliente.

## Control de acceso, auditoría y almacenamiento

* **Roles.** Las escrituras (`POST /traceback`, `/acknowledge`, `/respond`) requieren el
  rol de **owner o admin**, reflejando el resto de la superficie de escritura de cumplimiento.
  Las lecturas están disponibles para cualquier miembro autenticado de la organización.
* **Rastro de auditoría.** Cada cambio de estado escribe una entrada durable en el
  [log de auditoría](/compliance/consent-management) —
  `compliance.traceback.received`, `compliance.traceback.acknowledged` y
  `compliance.traceback.responded` — con el usuario actuante, la referencia ITG
  y (en una respuesta) la disposición y si el plazo se cumplió. El
  número implicado se enmascara en los detalles de auditoría.
* **Almacenamiento.** Los casos se almacenan en la configuración de su organización como
  claves generadas por el servidor, una por caso, para que dos compañeros trabajando casos diferentes (u
  otras configuraciones) concurrentemente nunca se sobrescriban entre sí.

## Vigilar el SLA

Incorpore el endpoint de lista a su ciclo de operaciones para que una brecha nunca sea una sorpresa:

1. Sondee `GET /traceback` en una cadencia regular (cada hora basta para una
   ventana de un día laborable).
2. Alerte cuando cualquier caso abierto reporta `sla.status: "due_soon"` o
   `sla.status: "breached"`, o `sla.breached: true`.
3. Avise al propietario de cumplimiento cuando aparezca una brecha — un traceback
   vencido es la señal que los operadores y la FCC pesan más.

El mismo patrón de veredicto en el momento del `GET` que alimenta la superficie de
[puntuaciones de salud de cumplimiento](/compliance/compliance-health) se aplica
aquí: las puntuaciones le avisan antes del throttling de los operadores, y los veredictos de traceback le
avisan antes de una escalación — trate ambos como fuentes de alerta temprana hacia su
postura de cumplimiento.

***

## Referencias relacionadas

* [Flujo de trabajo de traceback ITG en el dashboard](/guides/compliance-traceback-itg)
  — la guía del operador para la consola en **Settings → Compliance → ITG
  Traceback**.
* [Attestación STIR/SHAKEN](/channels/voice/stir-shaken) — la firma que
  crea la obligación de traceback, los niveles de attestación y los controles que usted
  posee.
* [Puertas de envío](/compliance/send-gates) — las verificaciones de horas de silencio, DNC, RND y RMD
  que se ejecutan en el momento del envío.
* [Puntuaciones de salud de cumplimiento](/compliance/compliance-health) — las puntuaciones de riesgo de 0–100
  para su organización, remitentes y campañas.
* [Resumen de postura de cumplimiento](/compliance/posture-overview) — cómo encajan
  las superficies de cumplimiento individuales.
* [Referencia de API → Compliance](/api-reference/endpoints/compliance) — esquemas
  completos de solicitud/respuesta (regenerados desde la API en vivo).