Deine Compliance-Integration entwerfen

Eine produktive Compliance-API-Integration trifft drei Designentscheidungen: wie sie den Activity Feed konsumiert, wie ihre Ausgabe mit deinem „security information and event management“-System (Sicherheitsinformations- und Ereignismanagement), oder SIEM, korreliert und wo langfristige Kopien von Aktivitäten und Inhalten liegen. Diese Entscheidungen sind unabhängig von den Endpunkten selbst; diese Seite hilft dir, die Abwägungen zu bewerten.

Diese Seite setzt voraus, dass du die folgenden Seiten gelesen hast:

• Den Activity Feed abfragen, die die Parameter und den Paginierungsvertrag definiert, auf die hier durchgehend verwiesen wird.
• Chats, Dateien und Projekte abrufen und löschen, die die Chat-, Datei- und Projekt-Endpunkte sowie die deleted_at-Semantik definiert, auf die in Aufbewahrung von Inhalten planen verwiesen wird.
• Sitzungstranskripte abrufen, die die Endpunkte für lokale und Remote-Sitzungen definiert.

Ein Muster für die Feed-Nutzung wählen

Der Activity Feed unterstützt zwei Nutzungsmuster: periodisches „window polling“ (Fenster-Polling), begrenzt durch created_at.gte und created_at.lt, sowie cursorgesteuerte inkrementelle Lesevorgänge, die einen Cursor aus einer Antwort persistieren und ihn bei der nächsten Anfrage übergeben. Beide liefern identische Activity-Objekte; der Unterschied liegt im Zustand, den dein Client zwischen den Aufrufen persistiert.

Beide Muster teilen diese Einschränkungen:

• Aktivitäten sind innerhalb von 1 Minute nach ihrem Auftreten abfragbar und werden 6 Jahre lang aufbewahrt. Die Aufzeichnung erfolgt nicht rückwirkend: Sie beginnt, wenn die Compliance API erstmals für deine Organisation aktiviert wird, und Aktivitäten aus der Zeit vor der Aktivierung werden nicht nachträglich aufgefüllt.
• Das maximale limit pro Seite beträgt 5.000.
• Cursor-Werte sind opake Zeichenketten, die du nicht parsen darfst.
• Anfragen sind auf 600 pro Minute pro übergeordneter Organisation begrenzt, geteilt über alle Keys, alle verknüpften Organisationen und alle /v1/compliance/*-Endpunkte hinweg; anders als die Endpunkte für lokale Sitzungen tragen die Endpunkte für Remote-Sitzungen zusätzlich ein zweites Anfragebudget. Siehe 429 Too Many Requests für die Antwort-Header und den Retry-Vertrag.

Fenster-Polling

Setze created_at.lt mindestens 1 Minute in die Vergangenheit, damit jede Aktivität im Fenster bereits abfragbar ist. Verwende created_at.gte für die untere Grenze und created_at.lt für die obere Grenze, damit aufeinanderfolgende Fenster lückenlos und ohne Überlappung aneinander anschließen; verwende den lt-Wert des vorherigen Fensters als gte des nächsten Fensters wieder.

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
  --data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
  --data-urlencode "limit=5000"

Wenn die Antwort has_more: true enthält, umfasst das Fenster mehr als eine Seite an Aktivitäten. Paginiere entweder innerhalb des Fensters, indem du die last_id der Antwort als after_id bei der nächsten Anfrage übergibst (und aufhörst, wenn has_more false ist), oder wähle ein kleineres Zeitfenster. Siehe Ergebnisse paginieren für den vollständigen Vertrag.

Selbst bei sauberem Aneinanderreihen erscheint eine Aktivität, die erst indexiert wird, nachdem ihr Fenster geschlossen wurde, nie in einem späteren Fenster. Dedupliziere anhand der Aktivitäts-id und erweitere entweder jedes neue Fenster so, dass es das vorherige um einige Minuten überlappt, oder führe einen periodischen Abgleichslauf durch, der ein älteres Fenster erneut abfragt.

Cursorgesteuerte inkrementelle Lesevorgänge

first_id="activity_01XyDMpzjS89pFZXqSFUBDr6"  # first_id from a previous response

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "limit=5000" \
  --data-urlencode "before_id=$first_id"

Blättere durch, bis has_more false ist, persistiere dann first_id aus der letzten Antwort und übergib sie unverändert als before_id beim nächsten Lauf, um Aktivitäten abzurufen, die neuer als der gespeicherte Cursor sind. Um für ein Backfill in die entgegengesetzte Richtung zu gehen, persistiere stattdessen last_id und übergib sie als after_id. Die vollständige Referenz zu Cursor vs. Page-Token und die Retry-Semantik findest du unter Ergebnisse paginieren.

Eine produktive Catch-up-Schleife ruft die seit deinem letzten Poll aufgezeichneten Aktivitäten ab, indem sie die Iteration über has_more und first_id steuert:

cursor = stored_cursor
loop:
  page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
  store(page.data)
  if page.first_id is not null:
    cursor = page.first_id
  if not page.has_more: break
persist(cursor)

Cursor überstehen die Key-Rotation; siehe Keys verwalten und rotieren.

Mit deinem SIEM korrelieren

Jede Activity trägt Felder, die du mit bereits in deinem SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl oder ähnlich) vorhandenen Ereignissen verknüpfen kannst:

actor.user_id und actor.email_address sind vorhanden, wenn actor.type user_actor ist. actor.ip_address und actor.user_agent fehlen bei einigen Akteurtypen, etwa anthropic_actor und scim_directory_sync_actor. Prüfe den Diskriminator, bevor du eines dieser Felder liest. user_id ist eine stabile, opake Kennung für das Benutzerkonto: Sie ist über alle Compliance-API-Endpunkte und Aktivitäts-Payloads hinweg konsistent und ändert sich nicht, wenn sich die E-Mail oder der Anzeigename des Benutzers ändert. Verwende user_id, nicht email_address, als primären Verknüpfungsschlüssel.

Aufrufe der Compliance API selbst erzeugen compliance_api_accessed-Aktivitäten. Nimm diese zusammen mit anderen Aktivitätstypen auf, damit dein SIEM aufzeichnet, wer wann Compliance-Daten abgefragt hat. Übergib activity_types[]=compliance_api_accessed, um die Abfrage einzugrenzen, und lies dann in deinem Client actor.api_key_id aus jeder Aktivität, deren actor.type api_actor ist, um den Zugriff einem bestimmten Compliance Access Key oder Admin-API-Key zuzuordnen.

Aufbewahrung von Inhalten planen

Fünf Aufbewahrungshorizonte bestimmen, was du später abrufen kannst:

Wie der Rest der Claude Platform mit Aufbewahrung umgeht, erfährst du unter API und Datenaufbewahrung.

Entscheide wie folgt zwischen Export-und-Archivierung und API-Abruf bei Bedarf:

• Wenn dein Legal-Hold- oder Audit-Horizont für Aktivitätsmetadaten oder Sitzungstranskripte 6 Jahre überschreitet, exportiere Activity-Feed-Seiten und Sitzungstranskripte in dein eigenes Archiv, während du sie aufnimmst.
• Wenn deine Richtlinie zur Aufbewahrung von Inhalten kürzer ist als dein eDiscovery-Horizont, exportiere Chat- und Dateiinhalte, bevor das Aufbewahrungsfenster abläuft; die Compliance API kann keine Inhalte zurückgeben, die die Aufbewahrung bereits entfernt hat. Dasselbe gilt für Transkripte lokaler Sitzungen, die dem benutzerdefinierten Aufbewahrungszeitraum für Unterhaltungen deiner Organisation folgen, wenn ein endlicher festgelegt ist, selbst wenn dieser Zeitraum kürzer als 6 Jahre ist. Die Endpunkte für lokale Sitzungen geben keine Nachrichten mehr zurück, die älter als der aktuelle Zeitraum deiner Organisation sind, sobald sich die Einstellung ändert, und eine spätere Verlängerung des Zeitraums stellt bereits abgelaufene Transkripte nicht wieder her; exportiere daher jedes Transkript, das du darüber hinaus aufbewahren musst.
• Wenn du Chat-Inhalte aufbewahren musst, nachdem Benutzer sie in claude.ai gelöscht haben (zum Beispiel im Rahmen eines Legal Hold), exportiere Chat-, Datei- und Artifact-Inhalte in dein eigenes Archiv, während du sie aufnimmst; die Compliance API kann keine Inhalte zurückgeben, die ein Benutzer bereits gelöscht hat.
• Wenn ein Workflow möglicherweise eine harte Löschung über die Compliance API auslöst (zum Beispiel DLP-Durchsetzung), rufe die Zielinhalte zuerst ab und archiviere sie. Nach einer harten Löschung gibt es kein Wiederherstellungsfenster.

In allen anderen Fällen verlasse dich auf den direkten API-Abruf und vermeide es, eine parallele Kopie zu pflegen.

Zustellgarantien und Vollständigkeit

Behandle den Activity Feed als at-least-once (mindestens einmal): Ein korrekt paginierter Durchlauf liefert jede Aktivität mindestens einmal, aber ein Retry nach einem Teilausfall kann Aktivitäten erneut zustellen, die du bereits gespeichert hast. Dedupliziere anhand des id-Felds der Aktivität.

Die List-Endpunkte geben weder ein total_count-Feld noch eine Prüfsumme zurück. Um zu belegen, dass ein Exportlauf vollständig ist, protokolliere:

• Den Start-Cursor und die abschließende last_id.
• Die Anzahl der exportierten Datensätze.
• Den Zeitstempel des Laufs und die request-id der letzten Seite.

Das Aktivitätsvolumen ist keine Vollständigkeitsprüfung. Die claude_*_viewed-Aktivitätstypen, etwa claude_chat_viewed, folgen dem Lademuster der jeweiligen App (siehe Das Activity-Objekt verstehen). Ein Zeitraum mit Chat-Nachrichten, aber ohne claude_chat_viewed-Aktivitäten, deutet für sich allein nicht auf fehlende Daten hin. Verlasse dich stattdessen auf den Durchlauf und den unter Fenster-Polling beschriebenen Überlappungs- oder Abgleichslauf.

Die Inhalts-Endpunkte (Chats, Dateien, Projekte, Projektanhänge sowie Transkripte lokaler und Remote-Sitzungen) liefern ausschließlich Claude-Enterprise-Daten. Der Activity Feed zeigt administrative und Ressourcen-Ereignisse organisationsweit an. Die Compliance API umfasst nicht:

• Prompt-Text oder Modellantworten aus der Claude Console oder aus Claude-API-Workloads, die mit einem API-Key authentifiziert sind.
• Geräteinterne Aktivitäten in lokalen Sitzungen, die nie an Anthropic gesendet werden, etwa lokale Dateien, die Claude nicht gelesen hat.
• Claude-Code-Nutzung, die mit einem Claude-Console-API-Key authentifiziert ist, über eine Drittanbieter-Cloud-Plattform (Amazon Bedrock, Google Cloud oder Microsoft Foundry) läuft oder in Claude Code im Web ausgeführt wird.
• Lokale Sitzungen von Organisationen mit aktivierter HIPAA-Bereitschaft sowie lokale Sitzungen, für die Zero Data Retention gilt.
• Thinking-Blöcke sowie Bilder oder andere Binärinhalte innerhalb von Sitzungstranskripten (Transkripte enthalten nur Benutzer-Prompts, Assistentenantworten und Tool-Aktivität; Transkripte lokaler Sitzungen zeigen einen Platzhalter-text-Block, wo Binärinhalte ausgelassen wurden).
• Die Originaldatei eines Chat-Anhangs, den claude.ai als extrahierten Text gespeichert hat, etwa manche Word-, PowerPoint- und PDF-Uploads (der Dateiinhalts-Endpunkt gibt den extrahierten Text zurück; siehe Dateien und Artifacts abrufen).
• Den System-Prompt lokaler Sitzungen (eine Markierungsnachricht steht an seiner Stelle).
• Tool-Definitionen und MCP-Server-Konfiguration in Sitzungstranskripten (lokal oder remote) sowie Zitations-Metadaten an text-Blöcken in Transkripten lokaler Sitzungen.
• Inhalte von Transkripten lokaler Sitzungen in einer Organisation, deren kundenverwalteter Verschlüsselungsschlüssel derzeit nicht verwendet werden kann. Diese Anfragen geben 503 Service Unavailable zurück, und Sitzungsmetadaten werden weiterhin aufgelistet.
• Inhalte, die durch die Aufbewahrungsrichtlinie deiner Organisation entfernt wurden.
• Inhalte von Chats, die Benutzer in claude.ai löschen (die Chats werden weiterhin aufgelistet, mit befülltem deleted_at).
• Über die Compliance API hart gelöschte Inhalte.

Mehr dazu, was die Compliance API erfasst und was nicht, findest du in den Compliance-API-FAQ.

Für die Beweiskette (Chain of Custody) speichere die exportierten Datensätze mit Herkunftsmetadaten: Quell-Endpunkt, Abfrageparameter, Zeitstempel des Laufs und einen Inhalts-Hash jedes Datensatzes.

Nächste Schritte