Die Endpunkte auf dieser Seite stellen Compliance-Prüfern die „transcripts" (Transkripte) der Sitzungen zur Verfügung, die deine Nutzer in Claude-Apps und -Agenten (heute Cowork und Claude Code) aus deinen Claude-Enterprise-Organisationen ausführen. Jede Sitzung ist eine einzelne Unterhaltung mit Claude; ihr Transkript ist die Abfolge von Nutzer-Prompts, Assistenten-Antworten sowie Tool-Aufrufen und -Ergebnissen in dieser Unterhaltung. Die Endpunkte unterstützen Exporte für „eDiscovery" (electronic discovery, elektronische Beweismittelerhebung) und die Durchsetzung von „data loss prevention" (Schutz vor Datenverlust), oder DLP.
Die Compliance API gruppiert Sitzungen je nach Ausführungsort in zwei Endpunktfamilien: Endpunkte für lokale Sitzungen („local sessions") für Sitzungen auf den Rechnern der Nutzer und Endpunkte für Remote-Sitzungen („remote sessions") für Sitzungen, die in der Cloud in von Anthropic verwalteten Umgebungen laufen. Beide Familien sind schreibgeschützt, und keine von beiden steht Admin-API-Keys (sk-ant-admin01-...) zur Verfügung: Aufrufe, die mit einem Admin-API-Key authentifiziert sind, geben 403 Forbidden zurück.
Die folgende Tabelle ordnet jedes Produkt und seinen Ausführungsort der Endpunktfamilie zu, die seine Sitzungen zurückgibt, sowie dem product_surface-Wert, der sie in Antworten kennzeichnet. Produkte werden dieser Tabelle hinzugefügt, sobald die Abdeckung erweitert wird.
| Produkt und Ausführungsort | Endpunktfamilie | product_surface |
|---|---|---|
| Cowork in Claude Desktop, ausgeführt auf dem Rechner des Nutzers | Endpunkte für lokale Sitzungen (/v1/compliance/apps/sessions/local) | cowork |
| Claude Code im Terminal, in Claude Desktop oder in einer IDE-Erweiterung, ausgeführt auf dem Rechner des Nutzers | Endpunkte für lokale Sitzungen | claude_code |
| Cowork-Sitzungen, die auf claude.ai im Web oder mobil gestartet wurden und in der Cloud in von Anthropic verwalteten Umgebungen laufen | Endpunkte für Remote-Sitzungen (/v1/compliance/apps/sessions/remote) | cowork_remote |
Die Erfassung lokaler Sitzungen ist daran gebunden, dass die Compliance API für deine Organisation aktiviert ist, und gilt, solange Nutzer mit ihrem Claude-Enterprise-Konto angemeldet sind. Die Sitzungsendpunkte geben Folgendes nicht zurück:
Die folgende Tabelle fasst zusammen, wie sich lokale Sitzungen und Remote-Sitzungen unterscheiden.
| Lokale Sitzungen (auf den Rechnern der Nutzer) | Remote-Sitzungen (in der Cloud) | |
|---|---|---|
| Endpunkte | List-, Retrieve- und Messages-Endpunkte unter /v1/compliance/apps/sessions/local | List- und Messages-Endpunkte unter /v1/compliance/apps/sessions/remote |
| ID-Präfix | clls_ | cse_ |
| Listenfilter | Nur created_at-Bereich | Organisation, Nutzer und created_at-Bereich |
| Lebenszyklusfelder | Keine: kein status oder updated_at | status, updated_at |
| Aufbewahrung | Standardmäßig 6 Jahre oder die benutzerdefinierte Aufbewahrungsfrist für Unterhaltungen deiner Organisation, wenn eine endliche festgelegt ist | 6 Jahre |
| Ratenlimits | Nur das gemeinsame Limit der Compliance API | Gemeinsames Limit der Compliance API plus ein zweites Anfragebudget |
| Löschung über die API | Nein | Nein |
Lokale Sitzungen laufen auf den Rechnern der Nutzer, während diese mit ihrem Claude-Enterprise-Konto angemeldet sind: heute Cowork in Claude Desktop sowie Claude Code im Terminal, in Claude Desktop oder in einer IDE-Erweiterung.
Die Compliance API stellt lokale Sitzungen über drei Endpunkte bereit: GET /v1/compliance/apps/sessions/local listet Sitzungsmetadaten auf, GET /v1/compliance/apps/sessions/local/{session_id} ruft die Metadaten einer Sitzung ab, und GET /v1/compliance/apps/sessions/local/{session_id}/messages gibt das Transkript einer Sitzung zurück. Alle drei erfordern den Scope read:compliance_user_data und zählen nur gegen das gemeinsame „rate limit" (Ratenlimit) der Compliance API; sie unterliegen nicht dem zweiten Anfragebudget, das für die Endpunkte für Remote-Sitzungen gilt. Siehe 429 Too Many Requests. Wenn lokale Sitzungen für deine übergeordnete Organisation nicht verfügbar sind, geben alle drei Endpunkte 404 mit der Meldung Local sessions are not available. zurück (siehe Lokale Sitzung nicht gefunden); solange Sitzungslisten oder erfasste Inhalte vorübergehend nicht verfügbar sind, geben sie 503 zurück (siehe Lokale Sitzungen vorübergehend nicht verfügbar).
Bei lokalen Sitzungen zeichnet Anthropic jede Unterhaltung serverseitig auf, sobald ihre Anfragen die Claude API erreichen; auf dem Gerät wird nichts installiert, und es wird nichts über die Anfragen hinaus erfasst, die der Client ohnehin an die Claude API sendet. Transkripte lokaler Sitzungen zeigen, was Claude tun sollte und was es zurückgegeben hat, nicht, was auf dem Gerät geschehen ist. Datei- und Netzwerkaktivität ist nur über die Tool-Aufrufe und Tool-Ergebnisse im Transkript sichtbar, sodass Aktivität, die die API nie erreicht (zum Beispiel lokale Dateien, die die Sitzung nie gesendet hat), nicht erfasst wird.
In Organisationen, die kundenverwaltete Verschlüsselungsschlüssel verwenden, werden lokale Sitzungen wie gewohnt aufgelistet und sind abrufbar, aber Transkriptinhalte werden derzeit nicht zurückgegeben; jede Nachricht kommt mit als nicht verfügbar markiertem Inhalt zurück (siehe Transkript einer lokalen Sitzung abrufen dazu, wie solche Nachrichten markiert werden).
Der List-Endpunkt gibt Sitzungsmetadaten ohne Transkriptinhalt für jede verknüpfte Organisation zurück, die dein Key lesen kann. Anders als die Liste der Remote-Sitzungen hat er keine Organisations- oder Nutzerfilter: Grenze die Ergebnisse zeitlich mit den Parametern created_at.gte und created_at.lt ein. Beide akzeptieren RFC-3339-Zeitstempel mit einem erforderlichen UTC-Offset, und wenn beide angegeben werden, muss created_at.lt strikt nach created_at.gte liegen, andernfalls gibt die Anfrage 400 Bad Request zurück. Neue Sitzungen und Nachrichten erscheinen nach einer kurzen Verarbeitungsverzögerung in den Ergebnissen, typischerweise innerhalb von Minuten; eine Sitzung, die unmittelbar nach ihrem Start fehlt, ist nicht zwangsläufig unerfasst. Die folgende Anfrage listet Sitzungen auf, die seit einem bestimmten Datum erstellt wurden.
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/apps/sessions/local" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "created_at.gte=2026-07-01T00:00:00Z" \
--data-urlencode "limit=100"{
"data": [
{
"type": "compliance_local_session",
"id": "clls_01HxKpLmNoPqRsTuVwXyZaBc",
"organization_uuid": "9a1e0000-0000-0000-0000-000000000000",
"workspace_id": "wrkspc_01SvYKoWVRVHoEbwESNvzYdR",
"user": {
"id": "user_01GpKpLmNoPqRsTuVwXyZaBc",
"email_address": "engineer@example.com"
},
"product_surface": "cowork",
"created_at": "2026-07-09T14:02:11Z"
},
{
"type": "compliance_local_session",
"id": "clls_01HyLqMnOpQrStUvWxYzAbCd",
"organization_uuid": "9a1e0000-0000-0000-0000-000000000000",
"workspace_id": null,
"user": {
"id": "user_01HqRsTuVwXyZaBcDeFgHiJk",
"email_address": null
},
"product_surface": "claude_code",
"created_at": "2026-07-08T09:15:43Z"
}
],
"next_page": "page_AAEfQx7mPdLkq9Rt2VwHbZk"
}Die Ergebnisse sind in umgekehrt chronologischer Reihenfolge (neueste zuerst) nach created_at sortiert, wobei Gleichstände in einer festen serverseitigen Reihenfolge aufgelöst werden, und auf limit Ergebnisse pro Antwort begrenzt (Standard 100, maximal 500). Der Endpunkt paginiert nur vorwärts mit page- und next_page-Token (siehe Ergebnisse paginieren): Übergib den next_page-Wert der Antwort bei der nächsten Anfrage als Query-Parameter page zurück und höre auf, wenn next_page null ist. Die Antwort hat kein has_more-Feld. Schließe einen Listendurchlauf innerhalb von 24 Stunden nach seinem Beginn ab; ein älterer Listen-Cursor wird weiterhin akzeptiert, aber gegen die aktuelle Aufbewahrungsgrenze neu ausgewertet, sodass Sitzungen, deren älteste aufbewahrte Aktivität kurz davor steht, aus der Aufbewahrungsfrist herauszufallen, übersprungen werden können.
In jedem Sitzungsobjekt ist user.id immer gesetzt und überdauert die Kontolöschung; user.email_address ist null, wenn das Konto des Nutzers gelöscht wurde oder der Nutzer nicht mehr Mitglied einer Organisation ist, die dein Key lesen kann. workspace_id ist null, wenn die Sitzung keinem Workspace zugeordnet war. Eine lokale Sitzung entspricht einer Client-Sitzungs-ID: Das Starten einer neuen Unterhaltung im Client oder das Leeren seines Kontexts beginnt einen neuen Sitzungsdatensatz. Behandle id-Werte als opake Zeichenketten; das Format kann sich ohne Vorankündigung ändern.
Lokale Sitzungen tragen kein status und kein updated_at: Eine lokale Sitzung hat keinen serverseitigen Lebenszyklus, und ihre Sichtbarkeit wird stattdessen durch die Aufbewahrung bestimmt. Eine lokale Sitzung wird als die Reihe von Claude-API-Aufrufen (Inferenzaufrufen) erfasst, die der Client während der Sitzung tätigt, und die Aufbewahrung gilt für jeden erfassten Aufruf einzeln. created_at ist der Zeitstempel des frühesten aufbewahrten Aufrufs der Sitzung (UTC). Wenn ältere Aufrufe die Aufbewahrungsfrist überschreiten, rückt created_at entsprechend vor, und sobald jeder Aufruf einer Sitzung herausgefallen ist, wird die Sitzung nicht mehr zurückgegeben. Da sich created_at zwischen Durchläufen verschieben kann, dedupliziere anhand von id, wenn du die Liste im Laufe der Zeit erneut durchläufst. Das created_at einer Sitzung verschiebt sich nicht nach hinten, während die Sitzung fortgesetzt wird, und es gibt kein updated_at, sodass eine Sitzung, die nach deinem ersten Export Nachrichten hinzugewinnt, nicht in einem späteren created_at-Fenster erneut erscheint. Um Transkripte aktuell zu halten, liste bei jedem Durchlauf ein nachlaufendes Fenster erneut auf, das mindestens so lang ist wie deine am längsten laufenden Sitzungen, und rufe die Transkripte der zurückgegebenen Sitzungen erneut ab, wobei du Nachrichten anhand von id deduplizierst.
Die Liste wird aus Metadaten zur Sitzungsaktivität erstellt und kann daher Sitzungen enthalten, deren Transkriptinhalt nicht erfasst wurde, zum Beispiel Sitzungen, die liefen, bevor die Erfassung für deine Organisation begann (so weit zurück, wie deine Aufbewahrungsfrist es erlaubt); das Transkript einer solchen Sitzung gibt jede Nachricht mit als nicht verfügbar markiertem Inhalt zurück (siehe Transkript einer lokalen Sitzung abrufen).
Erfasste Inhalte lokaler Sitzungen werden standardmäßig 6 Jahre ab Erfassung gespeichert. Wenn die Organisation, die die Sitzung ausgeführt hat, unter claude.ai > Organisationseinstellungen > Daten und Datenschutz eine endliche benutzerdefinierte Aufbewahrungsfrist für Unterhaltungen festgelegt hat, gilt stattdessen diese Frist, unabhängig davon, ob sie kürzer oder länger als der Standard ist; wenn die Organisation mehr als eine benutzerdefinierte Aufbewahrungsfrist konfiguriert hat, gilt die kürzeste. Eine Änderung dieser Einstellung wirkt sich auf zwei verschiedene Weisen aus: Die Endpunkte geben Aktivität, die älter als die aktuelle Frist der Organisation ist, nicht mehr zurück, sobald sich die Einstellung ändert, wohingegen jede erfasste Nachricht für die Frist gespeichert wird, die zum Zeitpunkt ihrer Erfassung galt, sodass eine spätere Verlängerung der Frist bereits abgelaufene Inhalte nicht wiederherstellt.
Um die Metadaten einer Sitzung direkt abzurufen, übergib ihre ID an GET /v1/compliance/apps/sessions/local/{session_id}. Die Antwort ist dasselbe Sitzungsobjekt, das der List-Endpunkt zurückgibt, ohne Umschlag und ohne Transkriptinhalt. Eine fehlerhaft formatierte Sitzungs-ID gibt 400 Bad Request zurück. Ein einziges 404 Not Found deckt vier Fälle ab, die die Antwort nicht unterscheidet: Die Sitzung befindet sich nicht in einer Organisation, die dein Key lesen kann (einschließlich Sitzungen unter einer anderen übergeordneten Organisation), sie existiert nicht, für sie gilt Zero Data Retention, oder jeder Aufruf in ihr hat die Aufbewahrungsfrist überschritten.
product_surface (String oder null) kennzeichnet das Produkt, das die Sitzung erstellt hat: cowork für Cowork-Sitzungen, die auf dem Rechner des Nutzers in Claude Desktop laufen, und claude_code für Claude-Code-Sitzungen. Neue Werte erscheinen, sobald die Abdeckung erweitert wird.
Der Messages-Endpunkt gibt das Transkript der Sitzung zurück, rekonstruiert aus den erfassten Claude-API-Aufrufen: Nutzer-Prompts, Assistententext, Tool-Aufrufe und die Textanteile von Tool-Ergebnissen, alle so zurückgegeben, wie sie gesendet wurden, abgesehen von Größenkürzungen. Nichts maskiert URLs, Zugangsdaten oder personenbezogene Daten in diesen Inhalten, behandle Transkripte daher als sensibel. Das Transkript lässt Folgendes aus oder ersetzt es:
[system prompt content not shown] steht an seiner Stelle (normalerweise einmal pro Sitzung; eine Sitzung ohne erfassten Inhalt trägt keine Markierung).text-Block mit dem Text [<block type> content not shown] (zum Beispiel [image content not shown]), wobei truncated auf true gesetzt ist. Nicht-Text-Elemente innerhalb eines Tool-Ergebnisses werden durch einen Eintrag [N non-text item(s) not shown] ersetzt, und truncated des Tool-Ergebnis-Blocks ist true.text-Blöcken werden ausgelassen, und der betroffene Block trägt truncated auf true gesetzt.Projektanweisungsdateien wie CLAUDE.md erscheinen als gewöhnlicher Inhalt mit der Rolle user. Skill-Inhalte erscheinen, wenn der Client sie als Nachrichteninhalt sendet, und werden nicht von anderem Nutzertext unterschieden. Eine Zusammenfassung der Abdeckung und einen Vergleich mit dem OpenTelemetry-Logging für Cowork und Claude Code findest du in den Compliance API FAQ.
session_id="clls_01HxKpLmNoPqRsTuVwXyZaBc"
curl --fail-with-body -sS \
"https://api.anthropic.com/v1/compliance/apps/sessions/local/$session_id/messages" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"{
"session": {
"type": "compliance_local_session",
"id": "clls_01HxKpLmNoPqRsTuVwXyZaBc",
"organization_uuid": "9a1e0000-0000-0000-0000-000000000000",
"workspace_id": "wrkspc_01SvYKoWVRVHoEbwESNvzYdR",
"user": {
"id": "user_01GpKpLmNoPqRsTuVwXyZaBc",
"email_address": null
},
"product_surface": "cowork",
"created_at": "2026-07-09T14:02:11Z"
},
"data": [
{
"type": "compliance_local_session_message",
"id": "clsm_01J4KpLmNoPqRsTuVwXyZaBa",
"role": "user",
"created_at": "2026-07-09T14:02:11Z",
"provenance": {
"type": "synthetic_marker"
},
"content": [
{
"type": "text",
"text": "[system prompt content not shown]",
"truncated": true
}
]
},
{
"type": "compliance_local_session_message",
"id": "clsm_01J4KpLmNoPqRsTuVwXyZaBc",
"role": "user",
"created_at": "2026-07-09T14:02:11Z",
"provenance": null,
"content": [
{
"type": "text",
"text": "Fix the failing test in tests/auth_test.py",
"truncated": false
}
]
},
{
"type": "compliance_local_session_message",
"id": "clsm_01J4KpLmNoPqRsTuVwXyZaBd",
"role": "assistant",
"created_at": "2026-07-09T14:02:11Z",
"provenance": null,
"content": [
{
"type": "text",
"text": "I'll read the test file first.",
"truncated": false
},
{
"type": "tool_use",
"id": "toolu_01AbCdEfGhIjKlMnOpQrSt",
"name": "Read",
"input": "{\"file_path\":\"tests/auth_test.py\"}",
"truncated": false
}
]
},
{
"type": "compliance_local_session_message",
"id": "clsm_01J4KpLmNoPqRsTuVwXyZaBe",
"role": "user",
"created_at": "2026-07-09T14:02:38Z",
"provenance": null,
"content": [
{
"type": "tool_result",
"tool_use_id": "toolu_01AbCdEfGhIjKlMnOpQrSt",
"name": "Read",
"is_error": false,
"content": [
{
"type": "text",
"text": "def test_login_expiry():\n ..."
}
],
"truncated": false
}
]
},
{
"type": "compliance_local_session_message",
"id": "clsm_01J4KpLmNoPqRsTuVwXyZaBf",
"role": "assistant",
"created_at": "2026-07-09T14:02:38Z",
"provenance": null,
"content": [
{
"type": "text",
"text": "The test was asserting on a stale expiry timestamp. I've updated it.",
"truncated": false
}
]
}
],
"next_page": null
}Die Antwort bettet einen session-Umschlag neben dem paginierten data-Array ein. Der erste Datensatz in diesem Beispiel ist die Markierung, die an der Stelle des System-Prompts der Anfrage steht; ihre provenance wird später in diesem Abschnitt beschrieben. Auf diesem Endpunkt ist user.email_address immer null: Der Messages-Endpunkt löst keine E-Mail-Adressen auf, ein null hier bedeutet also nicht, dass das Konto des Nutzers gelöscht wurde. Um eine Sitzung einer E-Mail-Adresse zuzuordnen, verknüpfe user.id mit dem List-Endpunkt oder dem Retrieve-Endpunkt (GET /v1/compliance/apps/sessions/local/{session_id}).
Nachrichten werden standardmäßig älteste zuerst zurückgegeben; übergib order=desc, um die Reihenfolge umzukehren. Die Paginierung verwendet dasselbe page/next_page-Schema wie der List-Endpunkt, mit einem limit-Standard von 100 und einem Maximum von 1.000. Eine Seite kann vorzeitig enden, wenn die Antwort ihr Größenlimit erreicht, eine Seite mit weniger als limit Nachrichten bedeutet also nicht, dass du das Ende erreicht hast; paginiere weiter, bis next_page null ist. Seiten-Cursor sind an die Sitzung und Sortierreihenfolge gebunden, unter der sie ausgegeben wurden, und die Cursor eines Durchlaufs laufen 24 Stunden nach seiner ersten Seite ab: Ein abgelaufener Cursor gibt 400 Bad Request zurück und fordert dich auf, ohne den page-Parameter neu zu beginnen, und der neu begonnene Durchlauf spiegelt die aktuelle Aufbewahrungsgrenze wider. Ein Cursor, der für eine andere Sitzung oder ein anderes order ausgegeben wurde, gibt ebenfalls 400 zurück, als ungültiger Cursor.
Jede Nachricht trägt eine role (user oder assistant) und ein content-Array aus text-, tool_use- und tool_result-Blöcken. Ein text-Block trägt text und truncated. Ein tool_use-Block trägt id, name, input und truncated, wobei input ein JSON-kodierter String und kein Objekt ist. Ein tool_result-Block trägt tool_use_id, name, is_error, ein content-Array aus text-Einträgen und truncated. MCP-Tool-Aufrufe und -Ergebnisse sowie die meisten Server-Tool-Aufrufe und -Ergebnisse werden in dieselben tool_use- und tool_result-Formen normalisiert; jeder andere Blocktyp erscheint als Platzhalter [<block type> content not shown]. Eine Nachrichten-id ist stabil, solange der Turn aufbewahrt wird. Jede Nachricht, die aus demselben Inferenzaufruf rekonstruiert wurde, trägt den Zeitstempel dieses Aufrufs, sodass aufeinanderfolgende Nachrichten oft denselben created_at-Wert teilen; bewahre die zurückgegebene Reihenfolge, statt nach Zeitstempel neu zu sortieren.
Jede Nachricht trägt außerdem ein provenance-Feld, das beschreibt, wie ihr Inhalt erfasst wurde. provenance ist null für verifizierte Inhalte, die von der Claude API erfasst wurden, was der übliche Fall ist. Andernfalls ist es ein Objekt, dessen type die Ausnahme kennzeichnet:
content_unavailable bedeutet, dass der Inhalt nicht zurückgegeben werden kann. Das content-Array ist leer, und provenance.reason gibt den Grund an. not_captured bedeutet, dass für den Turn kein Inhalt verfügbar ist; es beweist nicht, dass kein Datensatz gespeichert wurde, da Inhalte, die durch eine speicherseitige Zugriffsrichtlinie zurückgehalten werden, mit demselben Grund gemeldet werden (zum Beispiel in Organisationen, die kundenverwaltete Verschlüsselungsschlüssel verwenden), und einzelne Turns innerhalb einer ansonsten erfassten Sitzung aus anderen Gründen der Datenverarbeitung nicht verfügbar sein und denselben Grund tragen können. cmek_key_revoked ist für Inhalte reserviert, die unter dem kundenverwalteten Schlüssel deiner Organisation verschlüsselt sind, wenn dieser Schlüssel nicht verfügbar ist (zum Beispiel widerrufen); es wird derzeit nicht zurückgegeben, behandle es also für die Vorwärtskompatibilität. retention_elapsed bedeutet, dass der Inhalt die Aufbewahrungsfrist überschritten hat. oversize bedeutet, dass eine einzelne Nachricht die Größengrenze pro Nachricht überschritten hat; die Nachricht wird trotzdem zurückgegeben, mit einem leeren content-Array.client_asserted kennzeichnet Assistenten-Nachrichten, die der Client als Unterhaltungsverlauf geliefert hat und die keiner erfassten Antwort zugeordnet werden konnten; ihre Urheberschaft ist nicht verifiziert.synthetic_marker kennzeichnet Datensätze, die vom Endpunkt selbst erzeugt wurden, wie die Markierung, die an der Stelle des System-Prompts steht. Wenn der Client seinen Unterhaltungsverlauf mitten in der Sitzung umschreibt oder komprimiert (zum Beispiel nach einer Kontextkomprimierung), fügt das Transkript an dieser Stelle eine Markierungsnachricht ein und fährt mit dem neuen Inhalt fort, den der Client gesendet hat; wenn deine Organisation eine endliche Aufbewahrungsfrist hat, wird der umgeschriebene Verlauf selbst zurückgehalten (eine zweite Markierung weist darauf hin), und nur der letzte Nutzer-Turn und das Folgende werden angezeigt.Markierungs- und vom Client behauptete Nachrichten beginnen mit einem in eckige Klammern gesetzten erklärenden text-Block, der mit truncated: true gekennzeichnet ist, zum Beispiel [system prompt content not shown]. Behandle diese Datensätze als vorhanden, aber nicht verfügbar oder nicht verifiziert, statt als fehlend, und toleriere unbekannte provenance-Typen und -Gründe.
Zwei Parameter begrenzen, wie viele Bytes jedes Tool-Blocks zurückgegeben werden: tool_use_input_max_bytes und tool_result_max_bytes, beide mit einem Standard von 10.000 Bytes. Übergib -1 für das Server-Maximum (etwa 1 MiB pro String); 0 gibt 400 Bad Request zurück, und Werte über dem Maximum werden darauf begrenzt. Ein String, der durch eine der beiden Grenzen abgeschnitten wird, wird an einer Zeichengrenze abgeschnitten und erhält ein In-Band-Suffix angehängt (zum Beispiel …[truncated; pass tool_result_max_bytes=-1 for the server max]), und sein Block trägt "truncated": true. Ein gekürztes tool_use-input ist daher kein gültiges JSON mehr, parse Tool-Eingaben also nur aus ungekürzten Blöcken (oder erhöhe die Grenze und rufe erneut ab). Blöcke vom Typ text sind immer auf dasselbe Server-Maximum von etwa 1 MiB begrenzt; kein Parameter erhöht es, und ein text-Block an der Grenze trägt ebenfalls "truncated": true.
Transkriptinhalte berücksichtigen die unter Sitzungen auf den Rechnern der Nutzer beschriebene Aufbewahrungsfrist. Wenn der Beginn einer Sitzung diese überschritten hat, beginnt das Transkript mit einem einzelnen content_unavailable-Platzhalter mit reason gleich retention_elapsed, und die aufbewahrten Nachrichten folgen. Wenn jeder Aufruf einer Sitzung herausgefallen ist, gibt der Messages-Endpunkt 404 Not Found zurück, wie er es auch für Sitzungen in Organisationen tut, die dein Key nicht lesen kann, für Sitzungen, die nicht existieren, und für Sitzungen, für die Zero Data Retention gilt. Eine fehlerhaft formatierte Sitzungs-ID gibt 400 Bad Request zurück.
Cowork-Sitzungen, die auf claude.ai im Web oder mobil gestartet werden, laufen in der Cloud in von Anthropic verwalteten Umgebungen. Die Compliance API stellt diese Remote-Sitzungen über zwei Endpunkte bereit: GET /v1/compliance/apps/sessions/remote listet Sitzungsmetadaten auf, und GET /v1/compliance/apps/sessions/remote/{session_id}/messages gibt das Transkript einer Sitzung zurück. Beide erfordern den Scope read:compliance_user_data, und beide zählen gegen das gemeinsame Ratenlimit der Compliance API plus ein zweites, für diese Endpunkte spezifisches Anfragebudget; siehe 429 Too Many Requests.
Der List-Endpunkt verwendet standardmäßig den organisationsweiten Geltungsbereich: Lass organization_ids[] weg, um jede claude.ai-Organisation einzuschließen, die dein Key lesen kann, oder übergib bis zu 500 Werte, um den Geltungsbereich einzugrenzen. Um die Liste stattdessen auf bestimmte Nutzer einzugrenzen, übergib 1–10 user_ids[]-Werte (beziehe die IDs aus Organisationsnutzer auflisten); der Filter gleicht den besitzenden Nutzer der Sitzung ab, sodass agentenbesessene Sitzungen ausgeschlossen sind, sobald user_ids[] gesetzt ist. Grenze die Ergebnisse zeitlich mit created_at-Bereichsparametern ein (gte, gt, lt, lte, im RFC-3339-Format). Es gibt keinen updated_at-Filter. Die folgende Anfrage listet Sitzungen auf, die seit einem bestimmten Datum erstellt wurden.
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/apps/sessions/remote" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "created_at.gte=2026-06-01T00:00:00Z" \
--data-urlencode "limit=100"{
"data": [
{
"id": "cse_01WpQrStUvXyZaBcDeFgHjK6",
"organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
"user": {
"id": "user_01XyDMpzjS89pFZXqSFUBDr6",
"email_address": "user@example.com"
},
"agent_id": null,
"started_by_user": null,
"status": "active",
"created_at": "2026-07-01T17:04:05Z",
"updated_at": "2026-07-01T18:00:41Z",
"product_surface": "cowork_remote",
"claude_project_id": "claude_proj_01KGp4eZNug9ri4kE35RSppq"
},
{
"id": "cse_01TkNpRsUvWxYzAbCdEfGhJ4",
"organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
"user": null,
"agent_id": "cagt_01MnPqRsTuVwXyZaBcDeFgH8",
"started_by_user": {
"id": "user_01XyDMpzjS89pFZXqSFUBDr6",
"email_address": "user@example.com"
},
"status": "archived",
"created_at": "2026-06-28T09:15:22Z",
"updated_at": "2026-06-28T09:47:10Z",
"product_surface": "cowork_remote",
"claude_project_id": null
}
],
"next_page": "page_AAEfMk93cXpYdGxrZXk"
}Die Ergebnisse sind in umgekehrt chronologischer Reihenfolge (neueste zuerst) nach created_at sortiert und auf limit Ergebnisse pro Antwort begrenzt (Standard 100, maximal 500). Der Endpunkt paginiert mit page- und next_page-Token (siehe Ergebnisse paginieren): Übergib den next_page-Wert der Antwort bei der nächsten Anfrage als Query-Parameter page zurück und höre auf, wenn next_page null ist.
Eine Sitzung gehört entweder einem Nutzer oder einem Agenten, nie beiden. Bei nutzerbesessenen Sitzungen trägt user die ID und E-Mail-Adresse des Besitzers (email_address ist null, wenn der Nutzer nicht mehr Mitglied einer Organisation ist, die dein Key lesen kann), und agent_id ist null. Bei agentenbesessenen Sitzungen (zum Beispiel geplanten Aufgaben) ist user null, agent_id trägt die ID des Agenten (Präfix cagt_), und started_by_user identifiziert den Menschen, der den Lauf initiiert hat, zum Beispiel durch das Starten einer geplanten Aufgabe; bei nutzerbesessenen Sitzungen ist started_by_user null.
claude_project_id ist die ID des claude.ai-Projekts, zu dem die Sitzung gehört (Präfix claude_proj_), oder null, wenn die Sitzung in keinem Projekt ist.
status ist einer der Werte pending, active, paused, archived oder failed. Eine Sitzung ist pending, während sie bereitgestellt wird; eine pending-Sitzung hat noch kein Transkript, und der Messages-Endpunkt gibt für sie 404 zurück, bis die Bereitstellung abgeschlossen ist. Gelöschte Sitzungen werden nie zurückgegeben.
product_surface (String oder null) kennzeichnet das Produkt, das die Sitzung erstellt hat. Der Endpunkt gibt derzeit nur Sitzungen mit product_surface gleich cowork_remote zurück: Cowork-Sitzungen, die auf claude.ai im Web oder mobil gestartet wurden.
Der Messages-Endpunkt gibt das Transkript der Sitzung zurück: Nutzer-Prompts, Assistenten-Antworten sowie Tool-Aufrufe und -Ergebnisse. Thinking-Blöcke und Bilder sind nicht enthalten. Eine Zusammenfassung der Abdeckung und einen Vergleich mit dem OpenTelemetry-Logging von Cowork findest du in den Compliance API FAQ.
session_id="cse_01WpQrStUvXyZaBcDeFgHjK6"
curl --fail-with-body -sS \
"https://api.anthropic.com/v1/compliance/apps/sessions/remote/$session_id/messages" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"{
"session": {
"id": "cse_01WpQrStUvXyZaBcDeFgHjK6",
"organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
"user": {
"id": "user_01XyDMpzjS89pFZXqSFUBDr6",
"email_address": null
},
"agent_id": null,
"started_by_user": null,
"status": "active",
"created_at": "2026-07-01T17:04:05Z",
"updated_at": "2026-07-01T18:00:41Z",
"product_surface": "cowork_remote",
"claude_project_id": null
},
"data": [
{
"id": "csev_01HjKmNpQrStUvWxYzAbCdE2",
"role": "user",
"created_at": "2026-07-01T17:04:05Z",
"content": [
{
"type": "text",
"text": "Summarize the customer feedback in the attached spreadsheet.",
"truncated": false
}
],
"sent_by_user_id": null,
"content_unavailable": false
},
{
"id": "csev_01BcDeFgHjKmNpQrStUvWxY4",
"role": "assistant",
"created_at": "2026-07-01T17:04:06Z",
"content": [
{
"type": "text",
"text": "I'll start by reading the spreadsheet...",
"truncated": false
}
],
"sent_by_user_id": null,
"content_unavailable": false
}
],
"next_page": null
}Die Antwort bettet einen session-Umschlag neben dem paginierten data-Array ein. Auf diesem Endpunkt sind im Umschlag user.email_address, started_by_user und claude_project_id immer auf null gesetzt; beziehe diese Werte stattdessen vom List-Endpunkt.
Nachrichten werden standardmäßig älteste zuerst zurückgegeben; übergib order=desc, um die Reihenfolge umzukehren. Die Paginierung verwendet dasselbe page/next_page-Schema wie der List-Endpunkt, mit einem limit-Standard von 100 und einem Maximum von 1.000. Eine Seite kann vorzeitig enden, wenn die Antwort ihr Größenlimit erreicht, eine Seite mit weniger als limit Nachrichten bedeutet also nicht, dass du das Ende erreicht hast; paginiere weiter, bis next_page null ist.
Jede Nachricht trägt eine role (user oder assistant) und ein content-Array aus text-, tool_use- und tool_result-Blöcken. Die created_at-Werte von Nachrichten sind Commit-Zeitstempel: Aufeinanderfolgende Nachrichten können denselben Zeitstempel teilen oder leicht invertiert sein, bewahre also die zurückgegebene Reihenfolge, statt nach created_at neu zu sortieren. Bei agentenbesessenen Sitzungen hält sent_by_user_id den Nutzer fest, der eine bestimmte Nutzer-Nachricht gesendet hat, wenn einer zuordenbar ist; andernfalls ist es null, einschließlich bei allen Assistenten-Nachrichten. Wenn der Inhalt einer Nachricht überhaupt nicht zurückgegeben werden kann (zum Beispiel, weil er Größengrenzen überschreitet), trägt die Nachricht content_unavailable auf true gesetzt.
Zwei Parameter begrenzen, wie viele Bytes jedes Tool-Blocks zurückgegeben werden: tool_use_input_max_bytes und tool_result_max_bytes, beide mit einem Standard von 10.000 Bytes. Übergib -1 für das Server-Maximum (etwa 1 MiB pro String); 0 gibt 400 Bad Request zurück. Ein Block, der durch eine der beiden Grenzen abgeschnitten wird, trägt "truncated": true, und eine gekürzte tool_use-Eingabe ist kein gültiges JSON mehr, parse Tool-Eingaben also nur aus ungekürzten Blöcken (oder erhöhe die Grenze und rufe erneut ab).
Der Messages-Endpunkt gibt 404 Not Found für pending-Sitzungen, für Sitzungen, die nicht existieren oder gelöscht wurden, und für Sitzungen in Organisationen zurück, die dein Key nicht lesen kann.
Die Sitzungsendpunkte sind schreibgeschützt; lokale und Remote-Sitzungen können nicht über die Compliance API gelöscht werden. Transkripte lokaler Sitzungen werden standardmäßig 6 Jahre aufbewahrt oder für die benutzerdefinierte Aufbewahrungsfrist für Unterhaltungen deiner Organisation, wenn eine endliche festgelegt ist, wie unter Sitzungen auf den Rechnern der Nutzer beschrieben. Transkripte von Remote-Sitzungen werden 6 Jahre aufbewahrt. Wie sich diese Fristen zu den anderen Aufbewahrungsregelungen von Anthropic verhalten, findest du unter API und Datenaufbewahrung.
Greife mit demselben Compliance Access Key auf claude.ai-Chat-Inhalte, Dateianhänge und Projekte zu.
Eine Zusammenfassung der Abdeckung für Sitzungstranskripte und ein Vergleich mit OpenTelemetry-Logging.
Wörtliche Fehler-Payloads und die Lösung für jeden.
Endpunktpfade, Parameter und Antwortschemata für die Compliance API.
Was this page helpful?