​

ITG-Traceback-Fallbearbeitung

​

Warum Attestation diese Pflicht schafft

​

Fall-Lebenszyklus

• received — die ITG-Anfrage ist geloggt, noch nicht bearbeitet.
• acknowledged — Sie haben den ITG-Eingang bestätigt.
• responded — Sie haben Ihre Disposition bei der ITG eingereicht.
• closed — der Fall ist abgeschlossen (terminal; keine weiteren Übergänge).

​

Response-Deadline-SLA

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

​

Eine Traceback-Anfrage Schritt für Schritt behandeln

​

1. Die eingehende Anfrage loggen

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-Erneuerungs-Kampagne in einer Robocall-Beschwerde implant",
    "attestation": "A",
    "notes": "Erhalten über das ITG-Portal am 2026-08-26"
  }'

​

2. Eingang bestätigen

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": "Der ITG unter ihrer Referenz ITG-2026-11843 bestätigt"}'

​

3. Ihre Antwort einreichen

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": "Verkehr auf Unter-Konto supplier-7 zurückverfolgt; Quellenidentifikation der ITG geliefert.",
    "close": true
  }'

​

Dispositionen

​

4. Fälle prüfen

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"

​

Nur Protokollfläche

​

Zugriffskontrolle, Audit und Speicherung

• Rollen. Writes (POST /traceback, /acknowledge, /respond) brauchen die Owner- oder Admin-Rolle, spiegelnd dem Rest der Compliance-Schreibfläche. Reads sind für jedes authentifizierte Organisationsmitglied offen.
• Audit-Trail. Jede Zustandsänderung schreibt einen dauerhaften Audit-Log-Eintrag — compliance.traceback.received, compliance.traceback.acknowledged und compliance.traceback.responded — mit dem agierenden Benutzer, der ITG-Referenz und (bei einer Antwort) der Disposition und ob die Deadline gehalten wurde. Die implizierte Nummer ist in Audit-Details maskiert.
• Speicherung. Fälle sind auf den Einstellungen Ihrer Organisation als server-generierter, per-Fall-Key gespeichert, sodass zwei Teammitglieder verschiedene Fälle (oder andere Einstellungen) gegenseitig nie überschreiben.

​

Die SLA beobachten

1. Polling GET /traceback auf einer regelmäßigen Kadenz für ein Business-Day-Fenster reicht stündlich.
2. Alarmieren, wenn irgendein offener Fall sla.status: "due_soon" oder sla.status: "breached", oder sla.breached: true meldet.
3. Rufen Sie die Compliance-Eignerin, wenn ein Bruch auftritt — ein overdue Traceback ist das Signal, das Carrier und der FCC am schwersten tragen.

​

Verwandte Referenzen

• ITG-Traceback-Workflow im Dashboard — der Operator-Leitfaden für die Konsole unter Einstellungen → Compliance → ITG Traceback.
• STIR/SHAKEN-Attestation — die Signierung, die die Traceback-Pflicht schafft, Attestierungs-Level und die Kontrollen, die Sie besitzen.
• Send Gates — die Ruhezeiten-, DNC-, RND- und RMD-Prüfungen, die zum Sendezeitpunkt laufen.
• Compliance-Gesundheitswerte — die 0–100-Risikoscores für Ihre Organisation, Absender und Kampagnen.
• Compliance-Posture-Übersicht — wie die einzelnen Compliance-Flächen zusammenpassen.
• API-Referenz → Compliance — volle Request/Response-Schemas (aus der Live-API regeneriert).