Compliance-API-Fehler behandeln

Diese Seite listet häufige Fehlerantworten der Compliance API nach HTTP-Statuscode auf, jeweils mit Ursache und Lösung.

Die Compliance API gibt Fehler im standardmäßigen Anthropic-Fehlerformat zurück: einen Statuscode außerhalb des 2xx-Bereichs, einen request-id-Antwort-Header und einen JSON-Body mit einem error-Objekt, das type und message enthält. Gib den Wert des request-id-Headers an, wenn du dich an den Support wendest.

{
  "error": {
    "type": "permission_error",
    "message": "Missing required scopes. Got: ['read:compliance_activities'] Needed one of: ['read:compliance_user_data', 'read:org_audit']"
  }
}

Auf dieser Seite laufen lokale Sitzungen auf den Rechnern der Benutzer und Remote-Sitzungen in der Cloud; siehe Sitzungstranskripte abrufen.

Werte den HTTP-Statuscode und error.type aus, nicht den Nachrichtentext. Nachrichten sind stabil genug, um sie in Runbooks zu übernehmen, können aber im Laufe der Zeit umformuliert werden; die Statuscodes und Typwerte sind Teil des API-Vertrags. Einige Antworten, die denselben Statuscode und Typ teilen, werden durch einen Fehlercode in error.details.error_code unterschieden, sofern die Antwort einen enthält, und andernfalls durch ihre Nachricht; jeder dieser Fälle wird an der entsprechenden Stelle erläutert.

Die folgende Tabelle zeigt dir auf einen Blick, ob du es erneut versuchen solltest. Jeder nachfolgende Abschnitt zeigt den wörtlichen Fehler-Body und die Lösung.

400 Bad Request

Die Anfrage war syntaktisch gültig, aber der Server hat einen Parameter abgelehnt oder die Compliance API ist für die Organisation nicht aktiviert. Behebe die in der Nachricht genannte Ursache und sende die Anfrage erneut. Ein 400-Fehler ist anders: Transkriptseite zu groß, den der Messages-Endpunkt für lokale Sitzungen für eine Seite einer sehr großen Sitzung zurückgeben kann, selbst wenn alle Parameter gültig sind; sein Eintrag beschreibt, was du statt eines erneuten Sendens tun solltest.

Compliance API nicht aktiviert

Typ: invalid_request_error

Compliance API is not enabled for this organization

Ursache: Der Key ist gültig, aber die Compliance API ist für die Organisation oder übergeordnete Organisation, zu der der Key gehört, nicht aktiviert. Jeder Endpunkt gibt diese Antwort zurück, bis die API aktiviert ist, und erneut, wenn ein Administrator die API deaktiviert.

Lösung: Aktiviere die Compliance API, indem du Die Compliance API einrichten folgst, und sende die Anfrage dann erneut.

Unbekannter Query-Parameter

Typ: invalid_request_error

Unknown query parameter: 'created_at[gte]'. Did you mean 'created_at.gte'?

Ursache: Die Anfrage enthielt einen Query-Parameter, den der Endpunkt nicht definiert; die Compliance API lehnt unbekannte Parameter ab, anstatt sie zu ignorieren. Die Nachricht nennt den Parameter und schlägt bei knappen Abweichungen, etwa Klammernotation anstelle eines Punkts oder einem fehlenden []-Suffix, den definierten Namen vor.

Lösung: Verwende die Parameternamen, die auf der Compliance-API-Referenzseite des Endpunkts angegeben sind. Bereichsfilter verwenden Punktnotation (zum Beispiel created_at.gte), Array-Filter erhalten ein []-Suffix (zum Beispiel activity_types[]), und die Paginierungsparameter sind je nach Endpunkt after_id, before_id oder page.

Ungültiger Parameterwert

Typ: invalid_request_error

limit: Input should be less than or equal to 1000

created_at.gte: Input should be a valid datetime or date, invalid character in year

activity_types[].0: Input is not one of the permitted values.

Ursache: Der Wert eines Query-Parameters hat die Validierung nicht bestanden. Die Nachricht beginnt mit dem Parameternamen (bei einem Array-Parameter gefolgt von der Position des Elements) und nennt dann die nicht erfüllte Bedingung. Drei häufige Fälle werden gezeigt: ein limit über dem Maximum des Endpunkts (die Zahl in der Nachricht ist das Maximum dieses Endpunkts), ein created_at.*- oder updated_at.*-Wert, der nicht als Datum oder Zeitstempel geparst werden kann, und ein activity_types[]-Wert, der kein unterstützter Aktivitätstyp ist.

Lösung: Korrigiere den in der Nachricht genannten Parameter. Jeder Listen-Endpunkt hat seinen eigenen limit-Bereich; siehe die Parameterbeschränkungen auf der entsprechenden Compliance-API-Referenzseite. Sende Zeitstempel im RFC-3339-Format mit einem expliziten UTC-Offset, zum Beispiel 2024-03-01T00:00:00Z oder 2024-03-01T00:00:00+00:00; die Liste der lokalen Sitzungen lehnt einen Zeitstempel ohne Offset ab (created_at.gte: Input should have timezone info). Die unterstützten activity_types[]-Werte findest du unter Compliance-Aktivitäten abfragen.

Die Liste der lokalen Sitzungen (GET /v1/compliance/apps/sessions/local) gibt außerdem einen 400 invalid_request_error zurück, wenn du eine Untergrenze (created_at.gte oder created_at.gt) und eine Obergrenze (created_at.lt oder created_at.lte) angibst und die Obergrenze nicht nach der Untergrenze liegt. Gleiche Grenzen sind nur für created_at.gte mit created_at.lte zulässig. Die Nachricht nennt die beiden Parameter, zum Beispiel:

created_at.lt must be strictly after created_at.gte.

created_at.lte must be at or after created_at.gte.

Sende eine Obergrenze, die später als die Untergrenze liegt, oder lass eine der Grenzen weg.

Die Endpunkte für Sitzungstranskripte (GET /v1/compliance/apps/sessions/local/{session_id}/messages und GET /v1/compliance/apps/sessions/remote/{session_id}/messages) validieren ihre Kürzungsparameter auf dieselbe Weise: tool_use_input_max_bytes und tool_result_max_bytes akzeptieren jeweils eine positive Byte-Anzahl oder -1 (das Server-Maximum), sodass ein Wert wie 0 denselben 400 invalid_request_error zurückgibt.

Ungültiger Paginierungs-Cursor

Typ: invalid_request_error

Invalid activity_id format: 'activity_invalid123'

Invalid pagination cursor for 'after_id'

Ursache: Ein „pagination cursor" (Paginierungs-Cursor) konnte nicht dekodiert werden. Im Activity Feed gibt ein after_id- oder before_id-Wert, der weder ein von der API ausgegebener Cursor noch eine wohlgeformte Aktivitäts-ID ist, den ersten Body zurück, der den gesendeten Wert wiedergibt. Bei den Chat- und Chat-Nachrichten-Endpunkten gibt ein after_id- oder before_id-Wert, der nicht dekodiert werden kann, den zweiten Body zurück, der den Parameter nennt.

Lösung: Behandle Paginierungs-Cursor als undurchsichtige Zeichenketten. Kopiere immer den von der vorherigen Seite zurückgegebenen first_id- oder last_id-Wert; höre auf, wenn has_more den Wert false hat. Konstruiere keine Cursor aus Objekt-IDs.

Die Verzeichnis-, Projekt- und Sitzungs-Endpunkte (Organisationen, Benutzer, Rollen, Rollenberechtigungen, Gruppen, Gruppenmitglieder, Projekte, Projektanhänge, lokale und Remote-Sitzungen sowie Sitzungsnachrichten) paginieren mit einem undurchsichtigen page-Token statt mit after_id und before_id. Es gilt derselbe Rat: Übergib den next_page-Wert aus der vorherigen Antwort unverändert und höre auf, wenn has_more den Wert false hat (oder, bei den Sitzungs-Endpunkten, die kein has_more zurückgeben, wenn next_page den Wert null hat). Ein fehlerhaftes page-Token gibt denselben 400 invalid_request_error zurück wie ein fehlerhaftes after_id oder before_id, mit einer endpunktspezifischen Nachricht.

Die beiden paginierten Endpunkte für lokale Sitzungen (die Liste und der Messages-Endpunkt) geben den folgenden 400 invalid_request_error für jeden page-Wert zurück, den sie nicht dekodieren können, zum Beispiel ein Token, das nach dem Speichern gekürzt oder verändert wurde, oder eines, das von einem anderen Endpunkt oder unter einer anderen übergeordneten Organisation ausgegeben wurde. Beim Messages-Endpunkt für lokale Sitzungen (GET /v1/compliance/apps/sessions/local/{session_id}/messages) ist jeder page-Cursor außerdem an die Sitzung und die order gebunden, für die er ausgegeben wurde, sodass ein Cursor, der für eine andere Sitzung oder Sortierreihenfolge ausgegeben wurde, denselben Body zurückgibt:

The page parameter is not a valid cursor for this request.

Cursor beim Messages-Endpunkt laufen außerdem 24 Stunden nach Beginn des Durchlaufs (eines Durchgangs durch die Seiten) ab. Ein abgelaufener Cursor gibt Folgendes zurück:

The page cursor has expired. Restart the walk without a page parameter; results will reflect the current retention boundary.

Sende beim ersten Body den unveränderten next_page-Wert aus der vorherigen Antwort erneut an den Endpunkt und die Sitzung, die ihn ausgegeben haben. Starte bei einem abgelaufenen Cursor neu ohne page-Parameter; der neue Durchlauf spiegelt die Aufbewahrungsgrenze wider, die zu seinem Beginn gilt, sodass Nachrichten, die in der Zwischenzeit aus der Aufbewahrungsfrist herausgefallen sind, nicht mehr zurückgegeben werden (siehe Transkript einer lokalen Sitzung abrufen).

Transkriptseite zu groß

Typ: invalid_request_error

Fehlercode: transcript_page_read_limit_exceeded, zurückgegeben in error.details.error_code

This page of the session's transcript is too large to read, and retrying will not help. If you are reading newest first (order=desc), read this session oldest first instead: omit the order and page parameters, then follow next_page.

Ursache: GET /v1/compliance/apps/sessions/local/{session_id}/messages kann diesen Fehler für eine Seite einer sehr großen Sitzung zurückgeben. Nur dieser Endpunkt gibt diesen Fehler zurück. Er teilt den Typ invalid_request_error mit den anderen 400-Fehlern, also identifiziere ihn anhand seines Fehlercodes, nicht anhand des Nachrichtentexts, der umformuliert werden könnte.

Lösung: Versuche die Anfrage nicht erneut. Wenn sie order=desc verwendet hat, lies diese Sitzung stattdessen beginnend mit den ältesten Einträgen:

• Starte den Durchlauf der Sitzung (ein Durchgang durch ihre Seiten; siehe Transkript einer lokalen Sitzung abrufen) ohne order (oder mit order=asc) und ohne page neu und folge next_page, bis es null ist. Nachrichten, die du bereits aus dem Lesevorgang mit den neuesten zuerst gespeichert hast, behalten dieselbe id, also dedupliziere anhand von id.
• Setze das Anfrage-Timeout deines Clients für diesen Durchlauf auf mindestens 5 Minuten.
• Das Verringern von limit ist keine zuverlässige Methode, um diesen Fehler zu vermeiden.

Wenn eine Anfrage mit den ältesten zuerst diesen Fehler zurückgibt, versuche sie ebenfalls nicht erneut. Behalte die bereits gelesenen Seiten, vermerke die Sitzung als unvollständig, fahre mit dem Rest deines Exports fort und kontaktiere deinen Anthropic-Ansprechpartner mit dem request-id-Antwort-Header.

401 Unauthorized

Die Anfrage enthielt einen Compliance Access Key (sk-ant-api01-...) oder Admin-API-Key (sk-ant-admin01-...), der sich nicht authentifizieren lässt. Eine Anfrage ohne Key oder mit einem Key eines anderen Typs gibt stattdessen bei jedem Endpunkt außer den Organisationseinstellungen 404 Not Found zurück, und ein gültiger Key mit den falschen Scopes gibt 403 Forbidden zurück.

Ungültiger, deaktivierter oder abgelaufener API-Key

Typ: authentication_error

API key is invalid.

API key has been deactivated.

API key has expired.

Ursache: API key is invalid. bedeutet, dass der gesendete Wert keinem verwendbaren Key entspricht, zum Beispiel weil er beim Speichern gekürzt oder verändert wurde. API key has been deactivated. bedeutet, dass der Key deaktiviert oder gelöscht wurde. API key has expired. bedeutet, dass das Ablaufdatum eines Admin-API-Keys überschritten ist; Compliance Access Keys werden ohne Ablaufdatum erstellt.

Lösung: Vergleiche bei API key is invalid. den Wert, den dein Client sendet, mit dem Secret, das du beim Erstellen des Keys gespeichert hast; das vollständige Secret wird nur einmal angezeigt, also erstelle einen neuen Key, falls deine gespeicherte Kopie falsch ist. Aktiviere bei API key has been deactivated. den Key erneut, falls er nur deaktiviert wurde, und zwar unter claude.ai > Organisationseinstellungen > API für einen Compliance Access Key oder auf der Seite Admin keys (platform.claude.com/settings/admin-keys) in der Claude Console für einen Admin-API-Key; ein gelöschter Key kann nicht wiederhergestellt werden. Erstelle bei einem gelöschten oder abgelaufenen Key einen neuen Key und aktualisiere deine Integration, damit sie ihn verwendet, wie unter Keys verwalten und rotieren beschrieben.

403 Forbidden

Der Key in x-api-key ist gültig, trägt aber keinen „scope" (Berechtigungsbereich), den der Endpunkt akzeptiert. Die wörtliche Nachricht listet die Scopes auf, die der Key trägt (Got:), sowie die Scopes, die der Endpunkt akzeptiert (Needed one of: bei Lese-Endpunkten, bei denen ein beliebiger aufgeführter Scope ausreicht, oder Needed: bei Lösch-Endpunkten), sodass du prüfen kannst, was der Key trägt, ohne erneut in der Claude Console oder auf claude.ai nachzusehen. Bei Lese-Endpunkten enthält die Liste der akzeptierten Scopes außerdem read:org_audit, einen schreibgeschützten Audit-Scope, der jeden Lese-Endpunkt der Compliance API abdeckt; siehe Scopes für einen Claude-Enterprise-Key auswählen. Die Scopes eines Compliance Access Keys sind nach der Erstellung unveränderlich, daher weist dich jede Lösung für unzureichende Scopes an, einen neuen Key zu erstellen, anstatt den bestehenden zu bearbeiten. Eine eigenständige Claude-Console-Organisation (eine ohne übergeordnete Organisation) kann keinen Compliance Access Key erstellen, daher gelten Lösungen, die einen solchen erfordern, nicht für sie; sie kann nur den Activity Feed abfragen.

Unzureichender Scope: Activity Feed

Typ: permission_error

Missing required scopes. Got: ['read:compliance_user_data'] Needed one of: ['read:compliance_activities', 'read:org_audit']

Ursache: Ein Key ohne read:compliance_activities wurde verwendet, um GET /v1/compliance/activities aufzurufen. Es gibt zwei häufige Wege zu diesem Fehler:

• Ein Compliance Access Key (sk-ant-api01-...) wurde ohne den Scope read:compliance_activities erstellt.
• Ein Admin-API-Key der Claude Console (sk-ant-admin01-...) wurde erstellt, während die Compliance API für die Organisation nicht aktiviert war. Keys, die erstellt wurden, während die Compliance API nicht aktiviert war, tragen den Scope nicht; siehe Die Compliance API einrichten.

Lösung: Die Scopes eines Compliance Access Keys sind nach der Erstellung unveränderlich. Erstelle einen neuen Key, der read:compliance_activities enthält, oder verwende einen Admin-API-Key der Claude Console. Unter Welchen Key brauchst du? erfährst du, unter welchen Bedingungen ein Admin-API-Key diesen Scope trägt.

Unzureichender Scope: Organisationsdaten

Typ: permission_error

Missing required scopes. Got: ['read:compliance_user_data'] Needed one of: ['read:compliance_org_data', 'read:org_audit']

Ursache: Ein Key ohne read:compliance_org_data wurde verwendet, um einen Endpunkt für Organisationen, Rollen, Gruppen oder effektive Einstellungen aufzurufen. Es gibt zwei häufige Wege zu diesem Fehler:

• Ein Compliance Access Key (sk-ant-api01-...) wurde ohne den Scope read:compliance_org_data erstellt.
• Ein Admin-API-Key der Claude Console (sk-ant-admin01-...) wurde verwendet. Admin-API-Keys tragen nur read:compliance_activities und können keine Organisationsmetadaten lesen.

Lösung: Erstelle einen neuen Compliance Access Key mit ausgewähltem read:compliance_org_data. Admin-API-Keys können keine Organisationsmetadaten lesen; der Compliance Access Key ist erforderlich.

Eingestellter Scope: Organisationseinstellungen

Typ: permission_error

Missing required scopes. Got: ['read:compliance_org_settings'] Needed one of: ['read:compliance_org_data', 'read:org_audit']

Ursache: Der Scope read:compliance_org_settings wurde am 30. Juni 2026 eingestellt. GET /v1/compliance/organizations/{organization_id}/settings erfordert jetzt read:compliance_org_data, denselben Scope wie die anderen Organisations-Endpunkte, und der eingestellte Scope autorisiert nichts mehr. Ein Compliance Access Key, der nur read:compliance_org_settings trägt, gibt bei jedem Aufruf des Einstellungs-Endpunkts diesen Fehler zurück, obwohl der Key vor der Einstellung funktioniert hat. Der eingestellte Scope kann beim Erstellen eines Keys nicht mehr ausgewählt oder vergeben werden.

Lösung: Die Scopes eines Compliance Access Keys sind nach der Erstellung unveränderlich. Erstelle einen neuen Compliance Access Key mit ausgewähltem read:compliance_org_data, aktualisiere deine Integration so, dass sie ihn verwendet, und lösche dann den alten Key. Ein Key, der bereits read:compliance_org_data trägt, ist von der Einstellung nicht betroffen.

Unzureichender Scope: Benutzerdaten

Typ: permission_error

Missing required scopes. Got: ['read:compliance_activities'] Needed one of: ['read:compliance_user_data', 'read:org_audit']

Ursache: Ein Key ohne read:compliance_user_data wurde verwendet, um einen Endpunkt für Chats, Nachrichten, Dateien, Projekte, Sitzungen, Organisationsbenutzer oder Gruppenmitglieder aufzurufen. Es gibt zwei häufige Wege zu diesem Fehler:

• Ein Compliance Access Key (sk-ant-api01-...) wurde ohne den Scope read:compliance_user_data erstellt.
• Ein Admin-API-Key der Claude Console (sk-ant-admin01-...) wurde verwendet. Admin-API-Keys tragen nur read:compliance_activities und können read:compliance_user_data nicht erhalten, daher können sie die Endpunkte für Chats, Dateien, Projekte, Projektanhänge, Sitzungen, Benutzer oder Gruppenmitglieder nicht aufrufen.

Lösung: Verwende einen auf claude.ai erstellten Compliance Access Key mit ausgewähltem read:compliance_user_data. Falls die Anfrage tatsächlich nur den Activity Feed betreffen soll, richte den Admin-API-Key stattdessen auf GET /v1/compliance/activities.

Unzureichender Scope: Löschen

Typ: permission_error

Missing required scopes. Got: ['read:compliance_user_data'] Needed: ['delete:compliance_user_data']

Ursache: Ein Compliance Access Key ohne delete:compliance_user_data wurde verwendet, um einen DELETE-Endpunkt für Chats, Dateien oder Projekte aufzurufen.

Lösung: Erstelle einen neuen Compliance Access Key mit ausgewähltem delete:compliance_user_data. Der Lösch-Scope ist von read:compliance_user_data getrennt, damit schreibgeschützte Audit-Keys keine Inhalte löschen können.

404 Not Found

Ein 404, dessen Nachricht eine Ressource oder einen Ressourcentyp nennt, bedeutet, dass die ID im Pfad nicht existiert oder bereits gelöscht wurde. Löschvorgänge über die Compliance API erfolgen sofort und dauerhaft, daher bedeutet ein 404 bei einer zuvor bekannten ID in der Regel, dass der Inhalt verschwunden ist: endgültig gelöscht durch einen Löschaufruf der Compliance API, durch eine Aufbewahrungsrichtlinie entfernt oder, bei Dateien und Artefakten, zusammen mit ihrem Chat von einem Benutzer auf claude.ai gelöscht. Ein 404 mit der bloßen Nachricht Not found ist etwas anderes: Die Anfrage wurde nicht authentifiziert (oder der Pfad existiert nicht), und jeder Endpunkt kann ihn zurückgeben, einschließlich Listen-Endpunkten; siehe Anfrage nicht authentifiziert. Die Sitzungs-Endpunkte fügen zwei Fälle hinzu. Bei den Endpunkten für lokale Sitzungen wird eine separate 404-Nachricht, Local sessions are not available., bei jedem Aufruf (einschließlich der Liste) zurückgegeben, solange die Endpunkte für deine übergeordnete Organisation nicht verfügbar sind; sie hängt nicht von der Sitzungs-ID ab und kann vorübergehend sein. Siehe Lokale Sitzung nicht gefunden. Bei den Endpunkten für Remote-Sitzungen hat eine Sitzung, die noch bereitgestellt wird (status mit dem Wert pending), noch kein Transkript, daher liefert ihr Messages-Endpunkt einen 404, bis die Sitzung startet. Siehe Remote-Sitzung nicht gefunden. Die in jeder Lösung genannten Aktivitätstyp-Zeichenketten (zum Beispiel claude_chat_created) sind Werte, die du an den activity_types[]-Filter des Activity Feed übergeben kannst; alle unterstützten Werte findest du unter Compliance-Aktivitäten abfragen.

Anfrage nicht authentifiziert

Typ: not_found_error

Not found

Ursache: Die Anfrage enthielt keine Anmeldeinformation, die die Compliance API akzeptiert: Es wurde kein API-Key gesendet, oder der Key ist weder ein Compliance Access Key (sk-ant-api01-...) noch ein Admin-API-Key (sk-ant-admin01-...), zum Beispiel ein Claude-API-Key (sk-ant-api03-...). Status, Typ und Nachricht sind dieselben wie bei einem nicht existierenden Pfad und hängen weder vom Endpunkt noch von einer Ressourcen-ID ab, daher geben auch Listen-Endpunkte wie GET /v1/compliance/activities diesen Body zurück. Die einzige Ausnahme ist GET /v1/compliance/organizations/{organization_id}/settings, der solche Anfragen mit 401 authentication_error beantwortet. Bei jedem Endpunkt gibt ein Compliance Access Key oder Admin-API-Key, der sich nicht authentifizieren lässt, stattdessen 401 Unauthorized zurück.

Lösung: Sende den Key im x-api-key-Header und prüfe sein Präfix: Die Compliance API akzeptiert nur sk-ant-api01-...- und sk-ant-admin01-...-Keys; siehe Welchen Key brauchst du?. Wenn Header und Key korrekt sind und ein Pfad weiterhin Not found zurückgibt, während andere erfolgreich sind, prüfe diesen Pfad anhand der Compliance-API-Referenz.

Chat nicht gefunden

Typ: not_found_error

Chat conversation not found: 'claude_chat_01H5CWunD7RpVJ5bHa8RCkja'

Ursache: Die Chat-ID im Pfad entspricht keinem Chat, der über die Compliance API lesbar ist. Der Chat wurde möglicherweise durch einen früheren Aufruf der Compliance API endgültig gelöscht oder durch die Aufbewahrungsrichtlinie deiner Organisation entfernt, oder er gehört zu einer Organisation, die der aufrufende Key nicht lesen kann. Chats, die ein Benutzer auf claude.ai gelöscht hat, geben keinen 404 zurück; sie bleiben lesbar, mit befülltem deleted_at, jedoch ohne ihren Nachrichteninhalt.

Lösung: Gleiche die Chat-ID mit einer aktuellen claude_chat_created- oder claude_chat_viewed-Aktivität ab. Wenn die Aktivität aktuell ist und das Lesen trotzdem fehlschlägt, wurde der Chat endgültig gelöscht (über diese API oder durch Ablauf der Aufbewahrungsrichtlinie) oder gehört zu einer Organisation außerhalb des Bereichs deines Keys.

Datei nicht gefunden

Typ: not_found_error

File not found: 0d3b8f72-6c1e-4a59-b2de-7f4c9a1e5b60

Ursache: Die Datei-ID existiert in keiner Organisation, die dein Key lesen kann, oder die Datei wurde gelöscht. Das Löschen eines Chats auf claude.ai löscht auch die daran angehängten Dateien, obwohl der Chat selbst weiterhin aufgeführt wird. Die Nachricht identifiziert die Datei anhand ihrer zugrunde liegenden UUID statt anhand der in der Anfrage gesendeten claude_file_...-ID. Die Metadaten-, Inhalts- und Lösch-Endpunkte geben diesen Body zurück; er gilt sowohl für an Chats angehängte Dateien (claude_file_...) als auch für Projektdateien.

Lösung: Gleiche mit aktuellen claude_file_uploaded- oder claude_file_deleted-Aktivitäten ab. Für Dateien, die zusammen mit einem Chat gelöscht wurden, gibt es keine claude_file_deleted-Aktivität, prüfe daher auch die claude_chat_deleted-Aktivität des Chats. Wenn die Datei gelöscht wurde, ist die Binärdatei verschwunden; die Aktivitätsdatensätze verbleiben für das 6-jährige Aufbewahrungsfenster im Feed.

Generierte Datei oder Artefakt nicht gefunden

Typ: not_found_error

Generated file not found: 'claude_gen_file_01TbR8wAcCeFhJkLnPqStUvX'

Generated file content not found: 'claude_gen_file_01TbR8wAcCeFhJkLnPqStUvX'

Artifact version not found: 'claude_artifact_version_01KmNpQrSt3UvWxYz5AbCdEfG'

Ursache: Die ID im Pfad entspricht keiner von einem Tool generierten Datei oder Artefaktversion, die über die Compliance API lesbar ist. Der Metadaten-Endpunkt für generierte Dateien gibt den ersten Body zurück, der Inhalts-Endpunkt den zweiten, und beide Artefakt-Endpunkte geben den dritten zurück. Generierte Dateien und Artefakte werden zusammen mit dem Chat gelöscht, in dem sie erstellt wurden, auch wenn ein Benutzer den Chat auf claude.ai löscht.

Lösung: Verwende Chat-Nachrichten abrufen, um den Chat nachzuschlagen, aus dem die ID stammt. Wenn deleted_at des Chats befüllt ist oder eine claude_chat_deleted-Aktivität den Chat nennt, ist der Inhalt verschwunden; entferne die ID aus deiner Warteschlange. Andernfalls gleiche die ID mit den Arrays generated_files und artifacts in den Nachrichten des Chats ab.

Projekt nicht gefunden

Typ: not_found_error

No project is found with the provided id.

No project found with provided id, or it has already been deleted.

Ursache: Die Projekt-ID existiert nicht oder wurde gelöscht. Die Endpunkte für Projektdetails, Anhänge und Mitwirkende geben den ersten Body zurück; DELETE /v1/compliance/apps/projects/{project_id} gibt den zweiten zurück.

Lösung: Gleiche mit aktuellen claude_project_created- oder claude_project_deleted-Aktivitäten ab. Der Activity Feed stellt die Lebenszyklusereignisse des Projekts weiterhin bereit, auch nachdem das Projekt selbst verschwunden ist.

Projektdokument nicht gefunden

Typ: not_found_error

No project document found with the provided id.

No project document found with the provided id, or it has already been deleted.

Ursache: Die Projektdokument-ID existiert nicht oder wurde gelöscht. Die Inhalts- und Metadaten-Endpunkte für Dokumente geben den ersten Body zurück; DELETE /v1/compliance/apps/projects/documents/{document_id} gibt den zweiten zurück. Dieser Fehler gilt für Text-Projektdokumente (claude_proj_doc_...), nicht für Projektdateien.

Lösung: Verwende GET /v1/compliance/apps/projects/{project_id}/attachments, um die aktuellen Anhänge aufzulisten. Wenn das Dokument fehlt, wurde es gelöscht; rufe es über einen claude_project_document_uploaded-Aktivitätsdatensatz ab, falls du nur die Metadaten benötigst. Der Aktivitätsdatensatz zeigt, wer das Dokument wann und in welches Projekt hochgeladen hat, aber nicht seinen Namen.

Lokale Sitzung nicht gefunden

Typ: not_found_error

Local session not found.

Ursache: Die an GET /v1/compliance/apps/sessions/local/{session_id} oder GET /v1/compliance/apps/sessions/local/{session_id}/messages übergebene Sitzungs-ID entspricht keiner lokalen Sitzung, die über die Compliance API lesbar ist. Beide Endpunkte geben diese eine Nachricht zurück, ohne die Ursache zu unterscheiden, wenn die ID keine Sitzung in einer Organisation ist, die dein Key lesen kann (einschließlich IDs, die zu einer anderen übergeordneten Organisation gehören), wenn die Sitzung nie existiert hat, wenn für die Sitzung Zero Data Retention gilt oder wenn die gesamte Aktivität der Sitzung die Aufbewahrungsfrist überschritten hat, die für die Organisation gilt, in der sie ausgeführt wurde. Die Antwort Local session not found. hat keine vorübergehende Form, da lokale Sitzungen keinen Bereitstellungszustand (pending) haben; vergleiche Remote-Sitzung nicht gefunden, wo eine pending-Sitzung einen 404 liefert, bis sie startet. Eine Sitzungs-ID, die kein wohlgeformter clls_-Bezeichner ist, gibt stattdessen 400 Bad Request zurück.

Die Endpunkte für lokale Sitzungen, einschließlich des Listen-Endpunkts, geben eine andere 404-Nachricht zurück, Local sessions are not available., solange die Endpunkte selbst für deine übergeordnete Organisation nicht verfügbar sind. Diese Antwort hängt nicht von der Sitzungs-ID ab; kein kundenseitiger Key, Scope oder keine Einstellung ändert sie, und sie kann vorübergehend sein. Beide Antworten tragen den Typ not_found_error; der Nachrichtentext unterscheidet sie.

Lösung: Gleiche die Sitzungs-ID mit GET /v1/compliance/apps/sessions/local ab; siehe Sitzungen auf den Rechnern der Benutzer. Wenn die Sitzung nicht mehr in der Liste erscheint, hat ihr Inhalt die Aufbewahrungsfrist überschritten (oder die Sitzung befindet sich aus anderen Gründen nicht mehr in einer Organisation, die dein Key lesen kann), und ihr Transkript ist nicht abrufbar; entferne die ID aus deiner Warteschlange. Wenn jeder Aufruf, einschließlich der Liste, Local sessions are not available. zurückgibt, behalte deine Sitzungs-IDs in der Warteschlange und versuche es bei deinem nächsten geplanten Lauf erneut; wenn die Antwort bestehen bleibt, wende dich an deinen Anthropic-Ansprechpartner und gib den request-id-Antwort-Header an.

Remote-Sitzung nicht gefunden

Typ: not_found_error

Remote session not found.

Ursache: Die an GET /v1/compliance/apps/sessions/remote/{session_id}/messages übergebene Sitzungs-ID entspricht keinem Sitzungstranskript, das über die Compliance API lesbar ist. Dies tritt auf, wenn die Sitzungs-ID (cse_...) nicht existiert oder die Sitzung gelöscht wurde, wenn die Sitzung zu einer Organisation gehört, die dein Key nicht lesen kann, oder wenn der status der Sitzung noch pending ist: Eine ausstehende Sitzung hat noch kein Transkript, daher gibt der Messages-Endpunkt 404 zurück, bis die Sitzung startet. Eine Sitzungs-ID, die kein wohlgeformter cse_-Bezeichner ist, gibt stattdessen 400 Bad Request zurück.

Lösung: Gleiche die Sitzungs-ID und ihren status mit GET /v1/compliance/apps/sessions/remote ab; siehe Sitzungen in der Cloud. Wenn die Sitzung pending ist, versuche es erneut, nachdem sie diesen Status verlassen hat. Wenn die Sitzung nicht mehr in der Liste erscheint, wurde sie gelöscht, und ihr Transkript ist nicht abrufbar.

Organisation, Rolle oder Gruppe nicht gefunden

Typ: not_found_error

The "ce86b5f3-7c16-48b3-a9f3-e1d2c4b8a0f1" organization does not exist or the requester is not authorized to access it.

Die Endpunkte für Organisationen, Rollen und Gruppen geben einen 404 not_found_error im Standard-Fehlerformat zurück. Die Organisationsnachricht nennt die org_uuid; die Rollen- und Gruppennachrichten sind generisch (Role not found., Group not found.). Dies tritt auf, wenn eine Pfad-ID (org_uuid, role_id oder group_id) nicht existiert oder nicht mehr zu einem Baum gehört, den der aufrufende Key lesen kann.

Ursache: Die ID im Pfad entspricht keinem Datensatz, der über die Compliance API lesbar ist. Rollen und Gruppen können gelöscht werden, und Organisationen können vom übergeordneten Baum getrennt werden.

Lösung: Überprüfe die ID anhand des entsprechenden Listen-Endpunkts und gleiche sie mit aktuellen Organisations-, Rollen- oder Gruppenaktivitäten im Activity Feed ab.

Organisationseinstellungen nicht verfügbar

Typ: not_found_error

organization `91012d09-e48b-438e-a489-1bebfd8fa6f9` not found in this organization's hierarchy

Ursache: GET /v1/compliance/organizations/{organization_id}/settings gibt diesen 404 in drei Fällen zurück, die absichtlich denselben Body teilen, damit die Antwort nicht verrät, ob eine Organisation existiert: Die organization_id ist keine der verknüpften Organisationen deiner übergeordneten Organisation, der Wert ist keine gültige UUID, oder der Einstellungs-Endpunkt ist für deine übergeordnete Organisation noch nicht aktiviert.

Lösung: Überprüfe die ID anhand von Organisationen auflisten. Wenn eine bekanntermaßen gültige Organisations-ID weiterhin 404 zurückgibt, ist der Einstellungs-Endpunkt für deine übergeordnete Organisation noch nicht aktiviert; wende dich an deinen Anthropic-Ansprechpartner.

409 Conflict

Die Anfrage ist wohlgeformt und autorisiert, steht aber im Konflikt mit dem aktuellen Zustand der Ressource. Der Body trägt den Typ invalid_request_error, den auch 400-Antworten verwenden, unterscheide einen Konflikt daher anhand des Statuscodes 409 und nicht anhand von error.type.

Projekt hat angehängte Chats

Typ: invalid_request_error

The "claude_proj_01KGp4eZNug9ri4kE35RSppq" project cannot be deleted as it has chats attached to it. Delete or detach all chats, and try deleting the project again.

Ursache: DELETE /v1/compliance/apps/projects/{project_id} wurde für ein Projekt aufgerufen, an das noch Chats angehängt sind.

Lösung: Liste die Chats des Projekts mit GET /v1/compliance/apps/chats?user_ids[]={user_id}&project_ids[]={project_id} auf (der project_ids[]-Filter erfordert mindestens einen user_ids[]-Wert; ermittle die IDs über Organisationsbenutzer auflisten), lösche jeden einzelnen mit DELETE /v1/compliance/apps/chats/{claude_chat_id} und versuche dann erneut, das Projekt zu löschen.

429 Too Many Requests

Anfragen an die Compliance API sind auf 600 Anfragen pro Minute pro übergeordneter Organisation begrenzt. Das Limit ist ein einziges Budget, das von allen Keys unter der übergeordneten Organisation (Compliance Access Keys und die Admin-API-Keys aller verknüpften Organisationen) und von allen /v1/compliance/*-Endpunkten gemeinsam genutzt wird; die Endpunkte für Remote-Sitzungen haben zusätzlich ein zweites Anfragebudget. Für eine eigenständige Claude Console-Organisation, die keine übergeordnete Organisation hat, gilt dasselbe Budget für die Organisation selbst und wird von ihren Admin-API-Keys gemeinsam genutzt. Wende dich an deinen Anthropic-Ansprechpartner, wenn deine Integration ein höheres Limit benötigt.

Ein 429 ist anders: Bei einer sehr großen Sitzung kann der Endpunkt für lokale Sitzungsnachrichten Server beim Lesen großer Transkripte ausgelastet zurückgeben. Dies ist kein „rate limit" (Ratenlimit) und kein Limit für deine Organisation. Der zugehörige Eintrag am Ende dieses Abschnitts erklärt, wie du ihn erkennst und was zu tun ist.

Sobald sich dein API-Key authentifiziert hat, melden die Antworten der Compliance API das gemeinsame Budget über die standardmäßigen Ratenlimit-Antwort-Header, sodass dein Client proaktiv drosseln kann, anstatt auf einen 429 zu warten:

• anthropic-ratelimit-requests-limit ist das Anfragebudget pro Minute.
• anthropic-ratelimit-requests-remaining ist das im aktuellen Zeitfenster verbleibende Budget.
• anthropic-ratelimit-requests-reset ist der RFC-3339-Zeitstempel, zu dem das Zeitfenster zurückgesetzt und das volle Budget wiederhergestellt wird.

Eine 429-Antwort enthält außerdem einen retry-after-Header mit der Anzahl der Sekunden, die du vor dem Senden der nächsten Anfrage warten solltest. Dieser Wert kann eine kleine Sicherheitsmarge über anthropic-ratelimit-requests-reset hinaus enthalten; halte dich an retry-after.

HTTP/1.1 429 Too Many Requests
date: Tue, 21 Apr 2026 14:38:02 GMT
retry-after: 25
anthropic-ratelimit-requests-limit: 600
anthropic-ratelimit-requests-remaining: 0
anthropic-ratelimit-requests-reset: 2026-04-21T14:38:25Z

{
  "error": {
    "type": "rate_limit_error",
    "message": "Compliance API rate limit of 600 requests per minute per parent organization has been exceeded. Retry after the time indicated by the retry-after header. Quote the request-id response header when contacting Anthropic support."
  }
}

Ursache: Deine übergeordnete Organisation (oder eigenständige Claude Console-Organisation) hat innerhalb eines 1-Minuten-Fensters über alle Keys, die ihr Budget teilen, mehr als 600 Anfragen an /v1/compliance/* gesendet, oder sie hat das zweite Anfragebudget der Endpunkte für Remote-Sitzungen (weiter unten in diesem Abschnitt beschrieben) ausgeschöpft.

Lösung: Warte die Anzahl der Sekunden im retry-after-Header ab und versuche es dann erneut. Fehlt der Header (zum Beispiel, weil ein Zwischensystem ihn entfernt hat), greife auf exponentielles Backoff zurück (beginne bei 1 Sekunde, verdopple bis zu 60 Sekunden). Rücke deinen Paginierungs-Cursor bei einem 429 nicht vor: Die fehlgeschlagene Anfrage hat keine Daten zurückgegeben, daher ist der Cursor der letzten erfolgreichen Seite weiterhin korrekt.

Anfragen, deren Authentifizierung fehlschlägt (ein fehlender oder unbekannter Key oder ein Claude-API-Key anstelle eines Compliance Access Keys oder Admin-API-Keys), werden vor dem Ratenlimiter abgelehnt und verbrauchen kein Kontingent. Ein gültiger Key, dem der erforderliche Scope des Endpunkts fehlt, verbraucht eine Kontingenteinheit, bevor der 403 zurückgegeben wird.

Die Endpunkte für lokale Sitzungen zählen nur gegen das gemeinsame Limit. Die Endpunkte für Remote-Sitzungen haben zusätzlich ein zweites Anfragebudget, das wie das gemeinsame Limit an deine übergeordnete Organisation gebunden ist. Ein 429 aus diesem Budget enthält einen retry-after-Header, der immer 1 ist (eine Mindestwartezeit, nicht der tatsächliche Zeitpunkt des Zurücksetzens); alle anthropic-ratelimit-*-Header in dieser Antwort beschreiben das gemeinsame Limit und nicht dieses Budget, also verwende exponentielles Backoff, wenn sich der 429 wiederholt. Einer der 429-Fehler stammt aus keinem Anfragebudget: Server beim Lesen großer Transkripte ausgelastet, den nur der Endpunkt für lokale Sitzungsnachrichten zurückgibt.

Wenn du den Activity Feed nach einem Zeitplan abfragst, plane deine gesamte Anfragerate (über alle Keys, verknüpften Organisationen und parallelen Worker hinweg) unterhalb des gemeinsamen Limits ein. Beobachte anthropic-ratelimit-requests-remaining, um langsamer zu werden, bevor du es erreichst. Unter Deine Compliance-Integration entwerfen erfährst du, wie du zwischen Fenster-Polling und cursorgesteuerter Aufnahme wählst.

Server beim Lesen großer Transkripte ausgelastet

Typ: rate_limit_error

Fehlercode: transcript_read_server_busy, zurückgegeben in error.details.error_code

Too many large session transcripts are being read at once. This is not a limit on your organization. Retry this request after the number of seconds in the retry-after header.

Ursache: GET /v1/compliance/apps/sessions/local/{session_id}/messages kann diesen 429 für eine Seite einer sehr großen Sitzung zurückgeben. Nur dieser Endpunkt gibt diesen Fehler zurück, und er kann bei beiden order-Werten auftreten. Es handelt sich nicht um ein Ratenlimit und nicht um ein Limit für deine Organisation: Er bedeutet nicht, dass du das gemeinsame Limit oder ein anderes Anfragebudget überschritten hast. Dieser Fehler teilt den Statuscode 429 und den Typ rate_limit_error mit den Ratenlimit-Antworten, also erkenne ihn an seinem Fehlercode und nicht am Nachrichtentext, der umformuliert werden kann.

Lösung: Warte die Anzahl der Sekunden im retry-after-Header ab und sende dann dieselbe Anfrage unverändert erneut: Behalte denselben page-Wert bei, oder keinen, wenn die Anfrage keinen hatte. Gibt der erneute Versuch diesen Fehler wieder zurück, warte und versuche es auf dieselbe Weise erneut. Fehlt der retry-after-Header, greife auf exponentielles Backoff zurück (beginne bei 1 Sekunde, verdopple bis zu 60 Sekunden). Wenn dieser Fehler über mehrere Durchläufe hinweg immer wieder auftritt, wende dich an deinen Anthropic-Ansprechpartner und gib den request-id-Antwort-Header an.

500 Internal Server Error

Ein 500 von der Compliance API enthält einen x-should-retry: false-Antwort-Header, wenn der Fehler deterministisch ist. Das Claude SDK berücksichtigt diesen Header automatisch. Wenn du eine generische HTTP-Retry-Bibliothek verwendest, die bei jedem 5xx erneut versucht, unterdrücke Wiederholungen, wenn x-should-retry den Wert false hat; ein erneuter Versuch bei diesem Fehler schlägt bei jedem Versuch identisch fehl.

Ein 500 ohne den x-should-retry: false-Header ist vorübergehend: Versuche es mit exponentiellem Backoff erneut (beginne bei 1 Sekunde, verdopple bis zu 60 Sekunden). Dasselbe gilt für 502-, 503-, 504- und 529-Antworten. Die Ausnahme ist eine kleine Gruppe von 503-Fehlern bei lokalen Sitzungen, die im Folgenden beschrieben werden und von den Einstellungen oder dem Verschlüsselungsschlüssel einer Organisation statt von der Last abhängen. Unter Fehler findest du die plattformweite Retry-Semantik.

Lokale Sitzungen vorübergehend nicht verfügbar

Typ: overloaded_error

The local-sessions index is temporarily unavailable. Try again shortly.

Captured content is temporarily unavailable. Try again shortly.

The local-sessions index cannot currently evaluate retention overrides for this page. Try again later.

Ursache: Die Endpunkte für lokale Sitzungen geben 503 mit einem dieser Bodys zurück. Alle drei haben den Typ overloaded_error. Daher ist dies einer der wenigen Fehler auf dieser Seite, bei denen du den Nachrichtentext und nicht error.type brauchst, um die Bedingungen zu unterscheiden:

• Der Body index is temporarily unavailable bedeutet, dass Sitzungslisten wegen Last oder eines Backend-Zustands kurzzeitig nicht verfügbar sind. Dieser Zustand ist vorübergehend.
• Der Body Captured content bedeutet, dass der Transkriptinhalt einer Sitzung gerade nicht zurückgegeben werden kann. Auch das ist in der Regel vorübergehend. In Organisationen, die „customer-managed encryption keys" (kundenverwaltete Verschlüsselungsschlüssel) verwenden, gibt der Messages-Endpunkt diesen Body außerdem für jede Seite zurück, die Inhalte enthält, die dein kundenverwalteter Schlüssel nicht entschlüsseln kann. Das passiert zum Beispiel, wenn du den Schlüssel deaktiviert, widerrufen oder zerstört hast oder wenn der Schlüssel nicht erreichbar ist. In diesem Fall besteht der Fehler so lange, wie der Schlüssel nicht verwendet werden kann. Der Nachrichtentext ist in beiden Fällen derselbe. Das einzige Anzeichen dafür, dass der Schlüssel die Ursache ist, besteht also darin, dass der Fehler für diese Organisation immer wieder auftritt. Ein unbrauchbarer Schlüssel wird nie als not_captured gemeldet.
• Der Body retention overrides bedeutet, dass eine Aufbewahrungs- oder Datenverarbeitungseinstellung, die für eine oder mehrere Sitzungen im angeforderten Bereich gilt, noch nicht ausgewertet werden konnte. Bei den Retrieve- und Messages-Endpunkten lautet er for this session statt for this page. Er hängt nicht von der Last ab, sondern von den Daten und Einstellungen der Organisation, die die Sitzung ausgeführt hat, und kann über einen längeren Zeitraum bestehen bleiben.

Lösung: Behandle die einzelnen Bodys wie folgt:

• Bei den beiden Bodys mit Try again shortly. wiederholst du die Anfrage mit „exponential backoff" (exponentiellem Backoff). Setze deinen page-Cursor dabei nicht weiter, da die fehlgeschlagene Anfrage keine Daten zurückgegeben hat.
• Wenn der Body Captured content am Messages-Endpunkt für eine Organisation mit kundenverwaltetem Schlüssel immer wieder auftritt, behandle ihn als dauerhaft. Durchlaufe die Transkripte dieser Organisation nicht weiter und prüfe den Status des Schlüssels in deinem Schlüsselverwaltungsdienst. Transkripte in anderen verknüpften Organisationen und Sitzungsmetadaten sind davon nicht betroffen. Wenn du es in einem späteren Durchlauf erneut versuchst, starte den Durchlauf jeder Sitzung ohne page neu, da Messages-Seitencursor 24 Stunden nach der ersten Seite des Durchlaufs ablaufen.
• Beim Body mit Try again later. solltest du einen Durchlauf nicht offen halten, bis der Zustand behoben ist. Am Listen-Endpunkt hast du zwei Möglichkeiten: Versuche es später erneut und starte dabei ohne den Parameter page neu (ein Listen-Seitentoken, das älter als 24 Stunden ist, wird zwar weiterhin akzeptiert, aber anhand der aktuellen Aufbewahrungsgrenze neu ausgewertet, sodass ein pausierter Durchlauf Sitzungen überspringen kann), oder grenze das created_at-Zeitfenster ein, bis die Anfrage erfolgreich ist, und exportiere den übersprungenen Bereich in einem späteren Durchlauf separat. An den Retrieve- und Messages-Endpunkten überspringst du diese Sitzungs-ID, setzt den Rest deines Exports fort und versuchst es mit der Sitzung in einem späteren Durchlauf erneut. Messages-Seitencursor laufen 24 Stunden nach der ersten Seite des Durchlaufs ab. Starte den Durchlauf dieser Sitzung daher ohne page neu, wenn du zu ihr zurückkehrst.

Wenn eine dieser Bedingungen über mehrere Durchläufe hinweg wiederholt auftritt, wende dich an deinen Anthropic-Ansprechpartner und gib den Response-Header request-id an. Im Fall des kundenverwalteten Schlüssels tust du das nur, wenn der Fehler weiterhin auftritt, obwohl der Schlüssel verwendbar ist.

Informationen zu dienstweiten Störungen findest du unter status.anthropic.com.

Nächste Schritte