Compliance-API-Fehler behandeln

Diese Seite listet die Antwortnachrichten auf, die jeder dokumentierte Compliance-API-Endpunkt zurückgibt, sowie die Ursache und die Lösung.

Die Compliance API gibt Fehler im standardmäßigen Anthropic-Fehlerformat zurück: ein Nicht-2xx-Statuscode, ein request-id-Response-Header und ein 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": "authentication_error",
    "message": "The API key provided is invalid or has been revoked."
  }
}

Prüfe auf error.type, nicht auf den Message-String. Die Messages sind stabil genug, um sie in Runbooks zu kopieren, können aber im Laufe der Zeit umformuliert werden; die Type-Werte sind Teil des API-Vertrags. Die Local-Session-Endpunkte haben einige dokumentierte Ausnahmen, bei denen Antworten, die denselben Type teilen, anhand ihrer Message unterschieden werden; jede davon wird dort genannt, wo sie zutrifft.

Die folgende Tabelle zeigt dir auf einen Blick, ob du einen Retry durchführen solltest. Jeder nachfolgende Abschnitt zeigt den wortgetreuen Error-Body und die Lösung.



400 Bad Request

Die Anfrage war syntaktisch gültig, enthielt aber einen Parameter, den der Server abgelehnt hat. Korrigiere den Parameter und versuche es erneut.



Ungültiges Zeitstempelformat

Type: invalid_request_error

The `created_at.gte` parameter contains an invalid timestamp format. Timestamps must be provided in RFC 3339 format e.g., "2024-03-01T00:00:00Z". Got "2024-01-01".

Ursache: Ein created_at.*- oder updated_at.*-Wert (.gte, .gt, .lte, .lt) konnte nicht als Datetime geparst werden. Die Message nennt den Parameter, der fehlgeschlagen ist, und gibt den gesendeten Wert wieder.

Lösung: Sende einen vollständigen RFC-3339-Zeitstempel einschließlich Uhrzeit und Zeitzone, zum Beispiel 2024-03-01T00:00:00Z oder 2024-03-01T00:00:00+00:00.

Die Local-Session-Liste (GET /v1/compliance/apps/sessions/local) gibt ebenfalls einen 400 invalid_request_error zurück, wenn beide Zeitgrenzen angegeben sind und created_at.lt nicht strikt nach created_at.gte liegt. Der Body lautet:

created_at.lt must be strictly after created_at.gte.

Sende ein created_at.lt, das später als created_at.gte liegt, oder lasse eine der Grenzen weg.



Ungültiges Limit

Type: invalid_request_error

The limit parameter must be between 1 and 1000, inclusive. Got 1500.

Ursache: Der limit-Query-Parameter lag außerhalb des akzeptierten Bereichs. Die in der Message genannte Grenze spiegelt das Maximum für den spezifischen Endpunkt wider, der aufgerufen wurde.

Lösung: Sende ein limit innerhalb des Bereichs, den der Endpunkt akzeptiert. Jeder List-Endpunkt hat seinen eigenen limit-Bereich; siehe die Parameter-Einschränkungen auf der entsprechenden Compliance-API-Referenzseite.

Die Session-Transcript-Endpunkte (GET /v1/compliance/apps/sessions/remote/{session_id}/messages und GET /v1/compliance/apps/sessions/local/{session_id}/messages) validieren ihre Truncation-Parameter 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ültige Pagination-ID

Type: invalid_request_error

Invalid `after_id`. No activity found for `after_id` "activity_invalid123"

Ursache: Der after_id- oder before_id-Cursor konnte nicht als opaker Cursor dekodiert oder als Activity-ID geparst werden.

Lösung: Behandle Pagination-Cursor als opake Strings. Kopiere immer den first_id- oder last_id-Wert, der von der vorherigen Seite zurückgegeben wurde; stoppe, wenn has_more false ist. Konstruiere keine Cursor aus Objekt-IDs.

Die Directory-, Project- und Session-Endpunkte (Organisationen, Benutzer, Rollen, Rollenberechtigungen, Gruppen, Gruppenmitglieder, Projekte, Projekt-Attachments, Local- und Remote-Sessions sowie Session-Messages) paginieren mit einem opaken page-Token anstelle von after_id und before_id. Derselbe Rat gilt: Übergib den next_page-Wert aus der vorherigen Antwort unverändert und stoppe, wenn has_more false ist (oder, bei den Session-Endpunkten, die kein has_more zurückgeben, wenn next_page null ist). Ein fehlerhaftes page-Token gibt denselben 400 invalid_request_error zurück wie ein fehlerhaftes after_id oder before_id.

Beide Local-Session-Endpunkte (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 Parent-Organisation ausgestellt wurde. Beim Local-Session-Messages-Endpunkt (GET /v1/compliance/apps/sessions/local/{session_id}/messages) ist jeder page-Cursor außerdem an die Session und die order gebunden, für die er ausgestellt wurde, sodass ein Cursor, der für eine andere Session oder Sortierreihenfolge ausgestellt wurde, denselben Body zurückgibt:

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

Cursor auf dem Messages-Endpunkt laufen außerdem 24 Stunden nach Beginn des Walks (ein Durchlauf durch die Seiten) ab. Ein abgelaufener Cursor gibt zurück:

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

Für den ersten Body sende den unveränderten next_page-Wert aus der vorherigen Antwort erneut an den Endpunkt und die Session, die ihn ausgestellt haben. Für einen abgelaufenen Cursor starte ohne page-Parameter neu; der neue Walk spiegelt die Retention-Grenze wider, die zum Zeitpunkt seines Starts gilt, sodass Messages, die in der Zwischenzeit aus dem Retention-Zeitraum herausgefallen sind, nicht mehr zurückgegeben werden (siehe Ein Local-Session-Transcript abrufen).



401 Unauthorized

Der x-api-key-Header fehlte oder stimmte mit keinem bekannten Key überein. Ein gültiger Key mit den falschen Scopes gibt stattdessen 403 Forbidden zurück.



Ungültiger API-Key

Type: authentication_error

The API key provided is invalid or has been revoked.

Ursache: Der Key in x-api-key existiert nicht, wurde gelöscht oder wurde deaktiviert. Ein fehlender oder leerer x-api-key-Header gibt denselben Body zurück, also prüfe sowohl deinen Secret-Store als auch den Widerrufsstatus des Keys.

Lösung: Bestätige den Key-Wert, prüfe, dass er nicht in claude.ai (Compliance Access Keys) oder Claude Console (Admin-API-Keys) gelöscht wurde, und bestätige, dass er aktiviert ist. Siehe Compliance API einrichten.



403 Forbidden

Der Key in x-api-key ist gültig, trägt aber nicht den Scope, den der Endpunkt erfordert. Die wortgetreue Message listet die Scopes auf, die der Key trägt (Got:), und die Scopes, die der Endpunkt erfordert (Needed:), sodass du bestätigen kannst, was der Key trägt, ohne Claude Console oder claude.ai erneut zu prüfen. Compliance-Access-Key-Scopes sind nach der Erstellung unveränderlich, daher weist dich jede Insufficient-Scope-Lösung an, einen neuen Key zu erstellen, anstatt den bestehenden zu bearbeiten.



Unzureichender Scope: Activity Feed

Type: permission_error

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

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 read:compliance_activities-Scope erstellt.
• Ein Claude Console Admin-API-Key (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 Compliance API einrichten.

Lösung: Compliance-Access-Key-Scopes sind nach der Erstellung unveränderlich. Erstelle einen neuen Key, der read:compliance_activities enthält, oder verwende einen Claude Console Admin-API-Key. Siehe Welchen Key brauchst du? für die Bedingungen, unter denen ein Admin-API-Key diesen Scope trägt.



Unzureichender Scope: Organisationsdaten

Type: permission_error

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

Ursache: Ein Key ohne read:compliance_org_data wurde verwendet, um einen Organisations-, Rollen-, Gruppen- oder Effective-Settings-Endpunkt aufzurufen. Es gibt zwei häufige Wege zu diesem Fehler:

• Ein Compliance Access Key (sk-ant-api01-...) wurde ohne den read:compliance_org_data-Scope erstellt.
• Ein Claude Console Admin-API-Key (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

Type: permission_error

Missing required scopes. Got: ['read:compliance_org_settings'] Needed: ['read:compliance_org_data']

Ursache: Der read:compliance_org_settings-Scope 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 diesen Fehler bei jedem Aufruf des Settings-Endpunkts zurück, obwohl der Key vor der Einstellung funktioniert hat. Der eingestellte Scope kann beim Erstellen eines Keys nicht mehr ausgewählt oder gewährt werden.

Lösung: Compliance-Access-Key-Scopes sind nach der Erstellung unveränderlich. Erstelle einen neuen Compliance Access Key mit ausgewähltem read:compliance_org_data, aktualisiere deine Integration, um ihn zu verwenden, 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

Type: permission_error

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

Ursache: Ein Key ohne read:compliance_user_data wurde verwendet, um einen Chats-, Messages-, Files-, Projects-, Sessions-, Organization-Users- oder Group-Members-Endpunkt aufzurufen. Es gibt zwei häufige Wege zu diesem Fehler:

• Ein Compliance Access Key (sk-ant-api01-...) wurde ohne den read:compliance_user_data-Scope erstellt.
• Ein Claude Console Admin-API-Key (sk-ant-admin01-...) wurde verwendet. Admin-API-Keys tragen nur read:compliance_activities und können read:compliance_user_data nicht erhalten, sodass sie die Chat-, File-, Project-, Project-Attachment-, Session-, User- oder Group-Member-Endpunkte nicht aufrufen können.

Lösung: Verwende einen Compliance Access Key, der in claude.ai mit ausgewähltem read:compliance_user_data erstellt wurde. Wenn die Anfrage wirklich nur für den Activity Feed gedacht ist, richte den Admin-API-Key stattdessen auf GET /v1/compliance/activities.



Unzureichender Scope: Löschen

Type: 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, Files oder Projects aufzurufen.

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



404 Not Found

Der Endpunkt wurde aufgelöst, aber die Ressourcen-ID existiert nicht oder wurde bereits gelöscht. Compliance-API-Löschungen sind sofortig und dauerhaft, sodass ein 404 bei einer zuvor bekannten ID normalerweise bedeutet, dass der Inhalt durch einen Compliance-API-Delete-Aufruf hart gelöscht oder durch eine Retention-Policy entfernt wurde. Eine Ausnahme ist eine Remote-Session, die sich noch im Status pending befindet, deren Messages-Endpunkt vorübergehend 404 zurückgibt, bis die Session startet; siehe Remote-Session nicht gefunden. Die in jeder Lösung zitierten Activity-Type-Strings (zum Beispiel claude_chat_created) sind Werte, die du an den Activity-Feed-Filter activity_types[] übergeben kannst; siehe Compliance-Aktivitäten abfragen für jeden unterstützten Wert.

Local-Sessions haben keinen pending-Zustand, sodass ein Local session not found.-404 niemals vorübergehend ist; siehe Local-Session nicht gefunden für die Ursachen und für die separate Local sessions are not available.-Antwort, die nicht von der Session-ID abhängt und vorübergehend sein kann.



Chat nicht gefunden

Type: not_found_error

Chat claude_chat_01H5CWunD7RpVJ5bHa8RCkja not found.

Ursache: Die Chat-ID im Pfad stimmt mit keinem Chat überein, der über die Compliance API lesbar ist. Der Chat wurde möglicherweise durch einen vorherigen Compliance-API-Aufruf hart gelöscht oder durch die Retention-Policy deiner Organisation entfernt, oder er gehört zu einer Organisation, die der aufrufende Key nicht lesen kann. Chats, die ein Benutzer in claude.ai soft-gelöscht hat, geben kein 404 zurück; sie bleiben lesbar mit gefülltem deleted_at.

Lösung: Bestätige die Chat-ID anhand einer aktuellen claude_chat_created- oder claude_chat_viewed-Aktivität. Wenn die Aktivität aktuell ist und das Lesen weiterhin fehlschlägt, wurde der Chat hart gelöscht (über diese API oder durch Ablauf der Retention-Policy) oder gehört zu einer Organisation außerhalb des Scopes deines Keys.



Datei nicht gefunden

Type: not_found_error

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

Ursache: Die File-ID existiert nicht oder wurde gelöscht. Dieser Fehler 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. Wenn die Datei gelöscht wurde, ist die Binärdatei weg; der Activity-Eintrag bleibt für das 6-jährige Retention-Fenster im Feed.



Projekt nicht gefunden

Type: not_found_error

No project is found with the provided id.

Ursache: Die Project-ID existiert nicht oder wurde gelöscht.

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



Projektdokument nicht gefunden

Type: not_found_error

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

Ursache: Die Project-Document-ID existiert nicht oder wurde gelöscht. 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 aktuelle Attachments aufzulisten. Wenn das Dokument fehlt, wurde es gelöscht; rufe es über einen claude_project_document_uploaded-Activity-Eintrag ab, wenn du nur die Metadaten benötigst.



Remote-Session nicht gefunden

Type: not_found_error

Remote session not found.

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

Lösung: Bestätige die Session-ID und ihren status anhand von GET /v1/compliance/apps/sessions/remote; siehe Remote-Sessions abrufen. Wenn die Session pending ist, versuche es erneut, nachdem sie diesen Status verlassen hat. Wenn die Session nicht mehr in der Liste erscheint, wurde sie gelöscht und ihr Transcript ist nicht abrufbar.



Local-Session nicht gefunden

Type: 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 Session-ID stimmt mit keiner Local-Session überein, die über die Compliance API lesbar ist. Beide Endpunkte geben diese eine Message zurück, ohne die Ursache zu unterscheiden, wenn die ID keine Session in einer Organisation ist, die dein Key lesen kann (einschließlich IDs, die zu einer anderen Parent-Organisation gehören), wenn die Session nie existiert hat, wenn Zero Data Retention für die Session gilt oder wenn die gesamte Aktivität der Session den Retention-Zeitraum überschritten hat, der für die Organisation gilt, die sie ausgeführt hat. Im Gegensatz zu Remote-Sessions haben Local-Sessions keinen pending-Zustand, sodass die Local session not found.-Antwort keine vorübergehende Form hat. Eine Session-ID, die kein wohlgeformter clls_-Identifier ist, gibt stattdessen 400 Bad Request zurück.

Die Local-Session-Endpunkte, einschließlich des List-Endpunkts, geben eine andere 404-Message zurück, Local sessions are not available., während die Endpunkte selbst für deine Parent-Organisation nicht verfügbar sind. Diese Antwort hängt nicht von der Session-ID ab; kein kundenseitiger Key, Scope oder keine Einstellung ändert sie, und sie kann vorübergehend sein. Beide Antworten tragen den Type not_found_error; der Message-Text ist das, was sie unterscheidet.

Lösung: Bestätige die Session-ID anhand von GET /v1/compliance/apps/sessions/local; siehe Local-Sessions abrufen. Wenn die Session nicht mehr in der Liste erscheint, hat ihr Inhalt die Retention überschritten (oder die Session befindet sich anderweitig nicht mehr in einer Organisation, die dein Key lesen kann) und ihr Transcript ist nicht abrufbar; entferne die ID aus deiner Queue. Wenn jeder Aufruf, einschließlich der Liste, Local sessions are not available. zurückgibt, behalte deine in der Queue befindlichen Session-IDs und versuche es bei deinem nächsten geplanten Lauf erneut; wenn die Antwort andauert, kontaktiere deinen Anthropic-Ansprechpartner und gib den request-id-Response-Header an.



Organisation, Rolle oder Gruppe nicht gefunden

Type: not_found_error

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

Die Organisations-, Rollen- und Gruppen-Endpunkte geben einen 404 not_found_error im Standard-Fehlerformat zurück. Die Organisations-Message nennt die org_uuid; die Rollen- und Gruppen-Messages 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 stimmt mit keinem Eintrag überein, der über die Compliance API lesbar ist. Rollen und Gruppen können gelöscht werden, und Organisationen können vom Parent-Baum getrennt werden.

Lösung: Verifiziere die ID anhand des entsprechenden List-Endpunkts und gleiche mit aktuellen Organisations-, Rollen- oder Gruppen-Aktivitäten im Activity Feed ab.



Organisationseinstellungen nicht verfügbar

Type: 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 deines Parents, der Wert ist keine gültige UUID, oder der Settings-Endpunkt ist für deine Parent-Organisation noch nicht aktiviert.

Lösung: Verifiziere die ID anhand von Organisationen auflisten. Wenn eine bekanntermaßen gültige Organisations-ID weiterhin 404 zurückgibt, ist der Settings-Endpunkt für deine Parent-Organisation noch nicht aktiviert; kontaktiere deinen Anthropic-Ansprechpartner.



409 Conflict

Die Anfrage ist wohlgeformt und autorisiert, steht aber im Konflikt mit dem aktuellen Zustand der Ressource.



Projekt hat angehängte Chats

Type: conflict_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, das noch angehängte Chats hat.

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; enumeriere IDs über Organisationsbenutzer auflisten), lösche jeden einzelnen mit DELETE /v1/compliance/apps/chats/{claude_chat_id} und versuche dann das Löschen des Projekts erneut.



429 Too Many Requests

Anfragen an die Compliance API sind auf 600 Anfragen pro Minute pro Parent-Organisation begrenzt. Das Limit ist ein Budget, das über alle Keys unter dem Parent (Compliance Access Keys und die Admin-API-Keys aller verknüpften Organisationen) und über alle /v1/compliance/*-Endpunkte geteilt wird; die Remote-Session-Endpunkte tragen zusätzlich ein zweites Request-Budget. Für eine eigenständige Claude Console-Organisation, die keine Parent-Organisation hat, gilt dasselbe Budget für die Organisation selbst und wird über ihre Admin-API-Keys geteilt. Kontaktiere deinen Anthropic-Ansprechpartner, wenn deine Integration ein höheres Limit benötigt.

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

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

Eine 429-Antwort trägt außerdem einen retry-after-Header mit der Anzahl der Sekunden, die gewartet werden soll, bevor die nächste Anfrage gesendet wird. Dieser Wert kann eine kleine Sicherheitsmarge über anthropic-ratelimit-requests-reset hinaus enthalten; beachte 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 Parent-Organisation (oder eigenständige Claude Console-Organisation) hat mehr als 600 Anfragen an /v1/compliance/* in einem 1-Minuten-Fenster gesendet, über alle Keys hinweg, die ihr Budget teilen, oder sie hat das zweite Request-Budget der Remote-Session-Endpunkte erschöpft (später in diesem Abschnitt beschrieben).

Lösung: Warte die im retry-after-Header angegebene Anzahl von Sekunden, dann versuche es erneut. Wenn der Header fehlt (zum Beispiel von einem Intermediary entfernt), greife auf exponentielles Backoff zurück (beginne bei 1 Sekunde, verdopple bis zu 60 Sekunden). Rücke deinen Pagination-Cursor bei einem 429 nicht vor: Die fehlgeschlagene Anfrage hat keine Daten zurückgegeben, sodass der Cursor von der letzten erfolgreichen Seite weiterhin korrekt ist.

Anfragen, die bei der Authentifizierung fehlschlagen (ein fehlender oder nicht erkannter Key oder ein Claude-API-Key anstelle eines Compliance Access Keys oder Admin-API-Keys), werden vor dem Rate-Limiter 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 Remote-Session-Endpunkte tragen ein zweites Request-Budget, ebenfalls an deine Parent-Organisation gebunden, zusätzlich zum gemeinsamen Limit. Ein 429 aus diesem Budget trägt einen retry-after-Header, der immer 1 ist (eine Mindestwartezeit, nicht die tatsächliche Reset-Zeit); alle anthropic-ratelimit-*-Header in dieser Antwort beschreiben das gemeinsame Limit und nicht dieses Budget, also verwende exponentielles Backoff, wenn sich der 429 wiederholt. Die Local-Session-Endpunkte haben kein zweites Budget und zählen nur gegen das gemeinsame Limit.

Wenn du den Activity Feed nach einem Zeitplan abfragst, plane deine aggregierte Request-Rate (über alle Keys, verknüpften Organisationen und gleichzeitigen Worker) unterhalb des gemeinsamen Limits. Beobachte anthropic-ratelimit-requests-remaining, um zu verlangsamen, bevor du es erreichst. Siehe Deine Compliance-Integration entwerfen für die Wahl zwischen Window-Polling und Cursor-gesteuerter Ingestion.



500 Internal Server Error

Ein 500 von der Compliance API trägt einen x-should-retry: false-Response-Header, wenn der Fehler deterministisch ist. Anthropic-SDKs beachten diesen Header automatisch. Wenn du eine generische HTTP-Retry-Bibliothek verwendest, die bei jedem 5xx einen Retry durchführt, unterdrücke Retries, wenn x-should-retry false ist; ein Retry dieses Fehlers schlägt bei jedem Versuch identisch fehl.

Ein 500 ohne den x-should-retry: false-Header ist vorübergehend: Retry mit exponentiellem Backoff (beginne bei 1 Sekunde, verdopple bis zu 60 Sekunden). Dasselbe gilt für 502-, 503-, 504- und 529-Antworten. Ein Local-Session-503, der als Nächstes beschrieben wird, ist datenabhängig und nicht vorübergehend. Siehe Fehler für die plattformweite Retry-Semantik.



Local-Sessions vorübergehend nicht verfügbar

Type: 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 Local-Session-Endpunkte geben 503 mit einem dieser Bodies zurück. Die ersten beiden bedeuten, dass Session-Listings oder der erfasste Inhalt einer Session kurzzeitig nicht verfügbar sind; das ist ein vorübergehender Zustand im Zusammenhang mit Last oder dem Backend. Der dritte Body (der auf den Retrieve- und Messages-Endpunkten for this session statt for this page lautet) bedeutet, dass eine Retention- oder Data-Handling-Einstellung, die für eine oder mehrere Sessions im angeforderten Bereich gilt, noch nicht ausgewertet werden konnte. Das hängt von den Daten und Einstellungen der Organisation ab, die die Session ausgeführt hat, und nicht von der Last, und es kann über einen längeren Zeitraum andauern. Alle drei Bodies teilen den Type overloaded_error, sodass dies einer der wenigen Fälle auf dieser Seite ist, in denen der Message-Text und nicht error.type Zustände unterscheidet, die unterschiedliche Behandlung erfordern.

Lösung: Für die beiden Try again shortly.-Bodies führe einen Retry mit exponentiellem Backoff durch und rücke deinen page-Cursor nicht vor, da die fehlgeschlagene Anfrage keine Daten zurückgegeben hat. Für den Try again later.-Body halte keinen Walk offen, während du darauf wartest, dass er sich auflöst. Auf dem List-Endpunkt versuche es entweder später erneut, indem du ohne den page-Parameter neu startest (ein List-Page-Token, das älter als 24 Stunden ist, wird weiterhin akzeptiert, aber gegen die aktuelle Retention-Grenze neu ausgewertet, sodass ein geparkter Walk Sessions überspringen kann), oder verenge das created_at.gte- und created_at.lt-Fenster, bis die Anfrage erfolgreich ist, und exportiere den übersprungenen Bereich separat bei einem späteren Lauf. Auf den Retrieve- und Messages-Endpunkten überspringe diese Session-ID, fahre mit dem Rest deines Exports fort und versuche die Session bei einem späteren Lauf erneut; Messages-Page-Cursor laufen 24 Stunden nach der ersten Seite des Walks ab, also starte den Walk dieser Session ohne page neu, wenn du zu ihr zurückkehrst. Wenn der Zustand über mehrere Läufe hinweg wiederkehrt, kontaktiere deinen Anthropic-Ansprechpartner und gib den request-id-Response-Header an.

Für dienstweite Vorfälle prüfe status.anthropic.com.



Nächste Schritte