Gestalte deine Compliance-Integration

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 (System für Sicherheitsinformations- und Ereignisverwaltung), 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 Kompromisse abzuwägen.

Diese Seite setzt voraus, dass du Den Activity Feed abfragen gelesen hast, das die durchgehend referenzierten Parameter und den Paginierungsvertrag definiert, sowie Chats, Dateien und Projekte abrufen und löschen, das die Inhaltsendpunkte und die deleted_at-Semantik definiert, auf die in Inhaltsaufbewahrung planen verwiesen wird.



Wähle ein Feed-Konsummuster

Der Activity Feed unterstützt zwei Konsummuster: periodisches Fenster-Polling, begrenzt durch created_at.gte und created_at.lt, und cursorgesteuerte inkrementelle Lesevorgänge, die einen Cursor aus einer Antwort persistieren und ihn bei der nächsten Anfrage übergeben. Beide geben identische Activity-Objekte zurück; 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.
• Das maximale limit für jede Seite beträgt 5.000.
• Cursor-Werte sind opake Strings, die du nicht parsen darfst.
• Anfragen sind auf 600 pro Minute pro übergeordneter Organisation begrenzt, geteilt über jeden Key, jede verknüpfte Organisation und jeden /v1/compliance/*-Endpunkt; 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 ohne Lücken oder Überlappungen aneinandergereiht werden; verwende den lt-Wert des vorherigen Fensters als gte-Wert 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 stoppst, wenn has_more false ist), oder wähle ein kleineres Zeitfenster. Siehe Ergebnisse paginieren für den vollständigen Vertrag.

Selbst bei sauberer Aneinanderreihung erscheint eine Aktivität, die erst nach dem Schließen ihres Fensters indexiert wird, 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"

Paginiere, 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 einen Backfill in die entgegengesetzte Richtung zu laufen, persistiere stattdessen last_id und übergib sie als after_id. Für die vollständige Referenz zu Cursor vs. Page-Token und die Retry-Semantik siehe Ergebnisse paginieren.

Eine produktive Catch-up-Schleife ruft Aktivitäten ab, die seit deinem letzten Poll aufgezeichnet wurden, 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 überleben eine Key-Rotation; siehe Keys verwalten und rotieren.



Mit deinem SIEM korrelieren

Jede Activity enthält Felder, die du mit Ereignissen verknüpfen kannst, die bereits in deinem SIEM vorhanden sind (Splunk, Datadog, Microsoft Sentinel, Cribl oder ähnliche):

actor.user_id und actor.email_address sind vorhanden, wenn actor.type user_actor ist; prüfe den Diskriminator, bevor du sie liest. user_id ist ein stabiler, opaker Identifikator für das Benutzerkonto: Er ist über jeden Compliance-API-Endpunkt und jede Aktivitäts-Payload 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 Join-Key.

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.



Inhaltsaufbewahrung planen

Drei 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 On-Demand-API-Abruf:

• Wenn dein Legal-Hold- oder Audit-Horizont 6 Jahre für Aktivitätsmetadaten überschreitet, exportiere Activity-Feed-Seiten in dein eigenes Archiv, während du sie aufnimmst.
• Wenn deine Inhaltsaufbewahrungsrichtlinie 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.
• Wenn ein Workflow eine harte Löschung über die Compliance API auslösen könnte (zum Beispiel DLP-Durchsetzung), rufe die Zielinhalte zuerst ab und archiviere sie. Nach einer harten Löschung gibt es kein Wiederherstellungsfenster; Soft-Deletes aus claude.ai bleiben mit befülltem deleted_at abrufbar, Compliance-API-Löschungen jedoch nicht.

In jedem anderen Fall 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: Eine korrekt paginierte Traversierung gibt jede Aktivität mindestens einmal zurück, aber ein Retry nach einem Teilausfall kann Aktivitäten erneut liefern, die du bereits gespeichert hast. Dedupliziere anhand des Aktivitätsfelds id.

Die List-Endpunkte geben kein total_count-Feld und keine Prüfsumme zurück. Um zu bestätigen, 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.

Die Inhaltsendpunkte (Chats, Dateien, Projekte und Projektanhänge) liefern ausschließlich claude.ai-Daten; der Activity Feed zeigt administrative und Ressourcen-Ereignisse organisationsweit. Die Compliance API umfasst nicht:

• Prompt-Text oder Modellantworten aus Claude Console- oder Claude API-Workloads.
• Inhalte, die durch die Aufbewahrungsrichtlinie deiner Organisation entfernt wurden.
• Inhalte, die über die Compliance API hart gelöscht wurden.

Siehe die Compliance API FAQ für weitere Informationen darüber, was die Compliance API erfasst und was nicht.

Für die Beweiskette speichere die exportierten Datensätze mit Provenienz-Metadaten: Quell-Endpunkt, Abfrageparameter, Zeitstempel des Laufs und ein Inhalts-Hash jedes Datensatzes.



Nächste Schritte