Claude API kann nun einzelne Kunden sperren, statt gleich die ganze Organisation
Anthropic hat die Sperren der Claude API verfeinert: Künftig lässt sich ein einzelner problematischer Kunde blockieren, ohne dass alle Nutzer derselben Organisation betroffen sind. Ein angekündigtes Webhook-Feature ist dem Bericht zufolge noch nicht live.
Sie betreiben eine SaaS-Anwendung, ein Gateway oder einen Reseller-Dienst auf der Claude API. Jede Anfrage, die Sie im Namen Ihrer Kunden senden, geht unter einer einzigen Organisation ein: Ihrer. Anthropics eigene Dokumentation beschreibt offen, was das bis jetzt bedeutet hat: „Ein Endkunde kann eine Durchsetzungsmaßnahme auslösen, die sich auf Ihre gesamte Organisation auswirkt“ (Anthropic, User Profiles).
Am 20. Oktober hat Anthropic die Lösung ausgeliefert: User Profiles, mit denen Sie angeben können, für welchen Endkunden jede API-Anfrage bestimmt ist. Am 21. Oktober kamen die Felder enforcement_status und enforcement_actions hinzu, mit denen Sie sehen können, ob Anthropic einen Ihrer Kunden eingeschränkt oder gesperrt hat (Release Notes). MIXED News fasste es so zusammen, dass Reseller nun „einen einzelnen Kunden sperren lassen können, statt ihres gesamten Kontos“.
Doch in den Details lauert ein Haken. Der Webhook, der Sie eigentlich informieren soll, wenn ein Kunde gesperrt wird, existiert, lässt sich registrieren und sendet aber nichts. Anthropics Dokumentation sagt das in einer Notiz ganz offen: „Die Ereignisübermittlung ist nicht live“ (Organization Webhooks).
Ein Profil ist ein Datensatz, den Sie einmal pro Endkunden über POST /v1/user_profiles anlegen. Es gibt eine ID zurück, die mit uprof_ beginnt, und Sie senden diese ID bei jeder Anfrage für diesen Kunden im Header anthropic-user-profile-id mit (Dokumentation). Wenn eine Sicherheitsmaßnahme dieses Profil betrifft, bleibt laut derselben Seite „der Rest Ihres Traffics unberührt“.
Wer ein Profil bekommt, hängt davon ab, was Sie verkaufen. Ein registrierter Nutzer Ihrer Anwendung erhält ein Application-Profil, den Standard. Ein Unternehmen, dem Sie API-Zugang weiterverkaufen, erhält ein einziges Passthrough-Profil für das gesamte Unternehmen, nicht eines pro Mitarbeiter (Dokumentation). Eine Anfrage ohne Profil-ID zählt als Ihre eigene Nutzung, und Anthropic empfiehlt, diese Nutzung in einer separaten Organisation zu halten, da Profile zu einer Organisation gehören, nicht zu einem Workspace (Dokumentation).
Die SDKs übernehmen die ID als Argument. Dies ist der Python-Aufruf von Anthropics Seite, ergänzt um den Import und die gespeicherte ID und ohne die print-Ausgabe:
import anthropic profile_id = " uprof_... " # die ID, die Sie bei der Registrierung gespeichert haben client = anthropic. Anthropic () message = client. messages. create ( model = " claude-opus-5-5 ", max_tokens = 1024, messages = [{ " role ": " user ", " content ": " Hallo, Claude " }], user_profile_id = profile_id, ) Enter fullscreen mode Exit fullscreen mode Derselbe Header funktioniert auch beim Token-Zählen, bei Message Batches und beim OpenAI-SDK-Kompatibilitätsendpunkt (Dokumentation).
Mit einem Profil auf jeder Anfrage kann eine Einschränkung im Fenster eines einzelnen Kunden landen, statt im gesamten Gebäude.
1. Das Anlegen eines Profils ist nicht idempotent. „Jeder Aufruf erstellt ein neues Profil, selbst wenn reference_id mit einem bereits existierenden übereinstimmt“ (Dokumentation). Legen Sie es in Ihrem Onboarding-Flow an, speichern Sie die uprof_-ID am Kundendatensatz und lassen Sie jeden Service sie von dort lesen. Ein Worker, der beim Start create aufruft, erzeugt bei jedem Boot ein neues Profil.
2. Ein alter Beta-Header blendet die Sperrfelder aus. Die Antworten lassen enforcement_status und enforcement_actions weg, wenn Ihr anthropic-beta-Header den Wert user-profiles-2026-09-04 oder einen früheren trägt, und der Listenfilter enforcement_status[] liefert einen 400-Fehler (Webhooks-Dokumentation). Wenn Sie die Profile während der Beta übernommen haben, entfernen Sie diesen Wert.
3. Bedrock und Google Cloud schlagen das Profil nicht nach. Profile funktionieren auch für Claude in Amazon Bedrock und für Claude Models on Google Cloud (Google managed), aber Sie legen sie auf der Claude API oder der Claude Platform on AWS an. Diese beiden Plattformen prüfen nur das Format der ID. „Sie akzeptieren jede wohlgeformte ID, sodass eine erfolgreiche Antwort nicht bestätigt, dass die ID zu einem Profil passt“ (Dokumentation). Bei Bedrock landet die ID im Feld user_profile_id im Request-Body, nicht im Header, und die ältere InvokeModel- und Converse-Integration unterstützt sie überhaupt nicht.
4. Auf der Claude Platform on AWS zeigen die Felder immer unrestricted an. Dort ist enforcement_status immer unrestricted und die Aktionsliste immer leer, und Anthropic lehnt Anfragen dort nicht wegen einer offenen Maßnahme ab (Dokumentation).
5. Sie können ein Feld nicht leeren. Sie können einen Wert in external_user_details ersetzen, aber die API weist null mit einem 400-Fehler zurück (Dokumentation). Wenn Sie das Land eines Kunden nicht kennen, lassen Sie es lieber weg, statt einen Platzhalter zu senden, den Sie nie wieder entfernen können.
Jedes Profil meldet enforcement_status nun als unrestricted, restricted oder banned (die API-Referenz führt außerdem pending auf, solange eine Identitätsprüfung läuft). „Solange eine Maßnahme offen ist, lehnt Anthropic einige oder alle Inferenz-Anfragen ab, die die ID des Profils tragen“ (Dokumentation). Jeder Eintrag in enforcement_actions enthält einen Typ (restriction oder ban), einen Grund wie fraud_or_abuse oder account_compromise, eine Maßnahme, die der Kunde ergreifen kann, oder null, sowie eine Ablaufzeit expires_at oder null.
Die Dokumentation verrät auch, wie man mit Werten umgeht, die es noch gar nicht gibt: Behandeln Sie einen unbekannten enforcement_status als restricted und einen unbekannten Grund als unspecified (Dokumentation). Im Code ist das eine Zeile mit einem Fallback:
KNOWN = { " unrestricted ", " restricted ", " banned " } def effective_status ( raw: str ) -> str: # Anthropic kann Werte ergänzen; im Zweifel vorsichtig sein. return raw if raw in KNOWN else " restricted " Enter fullscreen mode Exit fullscreen mode Zu wissen, dass ein Kunde eingeschränkt ist, erlaubt Ihrer App, ihm eine echte Meldung anzuzeigen statt eines Stroms fehlgeschlagener Anfragen, und Ihr Support-Team kann den Grund sehen, bevor der Kunde ein Ticket eröffnet.
Anthropic hat außerdem Organization Webhooks in der Beta hinzugefügt, hinter dem Header webhooks-2026-10-07. Dort sind zwei Ereignisse definiert: user_profile.enforcement_action_opened und user_profile.enforcement_action_resolved. Für den Zugang kontaktieren Sie Ihr Anthropic-Account-Team (Dokumentation).
Dann folgt die Notiz: „Anthropic sendet die beiden Ereignisse nicht, daher erhält ein registrierter Endpunkt nichts“ (Dokumentation). Den Handler können Sie heute schon bauen. Verlassen können Sie sich auf ihn heute noch nicht.
Der Enforcement-Webhook ist vorerst mit nichts verbunden. Eine geplante Abfrage ist die Klingel, die funktioniert.
Auch wenn die Übermittlung live geht, beschreibt die Dokumentation einen Webhook, den man nicht als alleinige Wahrheitsquelle behandeln kann (Dokumentation):
Die Zustellungen folgen der Standard-Webhooks-Spezifikation, daher verifizieren Sie den Header webhook-signature mit dem whsec_-Secret Ihres Endpunkts und antworten innerhalb von 5 Sekunden mit einem 2xx, bevor Sie langwierige Arbeit erledigen (Dokumentation).
Jeder der oben beschriebenen Wege endet beim selben Aufruf. Anthropics eigener Rat zum Nachziehen ist, Ihre Profile nach Status gefiltert aufzulisten (Dokumentation):
curl -g "https://api.anthropic.com/v1/user_profiles \?enforcement_status[]=restricted&enforcement_status[]=banned" \ -H "x-api-key: $ANTHROPIC_API_KEY " \ -H "anthropic-version: 2023-06-01" Enter fullscreen mode Exit fullscreen mode Das Flag -g verhindert, dass curl die eckigen Klammern als Glob-Muster behandelt. Eine Seite kann weniger Profile als limit zurückliefern oder gar keine, bevor die Liste zu Ende ist, fordern Sie also weiter Seiten an, bis next_page null ist (Dokumentation). Außerdem bewegt eine Statusänderung „updated_at nicht zuverlässig“, vergleichen Sie daher die beiden Enforcement-Felder mit den zuletzt gespeicherten Werten, nicht mit dem Zeitstempel (Dokumentation).
Führen Sie das jetzt nach einem Zeitplan aus. Sobald die Ereignisübermittlung live geht, behalten Sie den Job als Abgleichsschritt hinter dem Webhook bei. Der Webhook informiert Sie früher; der geplante Listen-Aufruf fängt alles auf, was er wiederholt, neu anordnet oder verliert.
Profile sind optional, sodass eine Plattform, die sie überspringt, das alte Risiko behält (MIXED News). Wenn Sie Traffic für andere senden, ist das Anlegen eines Profils pro Kunde und das Mitsenden eines Headers ein günstiger Weg, zu verhindern, dass die Sperre eines schlechten Kunden auf alle anderen fällt. Legen Sie Profile bei der Registrierung an, oder füllen Sie zunächst einen bestehenden Kundenbestand nach?
Ein Sperr-Webhook, der Ereignisse wiederholen, neu anordnen und verlieren kann, ist der Lehrbuchfall für idempotente Consumer und einen Abgleichsjob. Wenn Sie einen solchen einrichten, führt mein Event-Driven Architecture Pocket Guide durch die ereignisgetriebenen Muster dazu: Sagas, CQRS, das Outbox-Muster und die Fallstricke, vor denen niemand warnt. Es ist eines von 8 kurzen Büchern der Reihe Pocket Guides for Developers, die Agents, RAG, Prompts, Observability, Events, Datenbanken und Systemdesign abdeckt.
Ich baue außerdem Hermes IDE, eine kostenlose Desktop-App, um Claude Code, Codex und andere Coding-Agents nebeneinander zu betreiben, jeweils auf einem eigenen Branch: Laden Sie sie herunter oder vergeben Sie einen Stern auf GitHub.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
You run a SaaS app, a gateway or a reseller on the Claude API. Every request you send for your customers arrives under one organization: yours. Anthropic's own docs spell out what that has meant until now: "one end customer can trigger an enforcement action that applies to your whole organization" ( Anthropic, user profiles ).
On October 20, Anthropic shipped the fix: user profiles, so you can tell it which end customer each API request is for. On October 21 it added enforcement_status and enforcement_actions fields, so you can see whether Anthropic has restricted or banned one of your customers ( release notes ). MIXED News summed it up as resellers being able to get "one customer banned instead of their whole account."
There's a catch in the fine print. The webhook that's supposed to tell you when a customer gets banned exists, takes registrations, and sends nothing. Anthropic's docs say so in a note: "Event delivery isn't live" ( organization webhooks ).
A profile is a record you create once per end customer with POST /v1/user_profiles. It returns an ID that starts with uprof_, and you send that ID in the anthropic-user-profile-id header on every request you make for that customer ( docs ). When a safety action hits that profile, "the rest of your traffic is unaffected," per the same page.
Who gets a profile depends on what you sell. A signed-up user of your app gets an application profile, the default. A company you resell API access to gets one passthrough profile for the whole company, not one per employee ( docs ). A request with no profile ID counts as your own usage, and Anthropic recommends keeping that usage in a separate organization, because profiles belong to an organization, not a workspace ( docs ).
The SDKs take the ID as an argument. This is the Python call from Anthropic's page, with the import and the stored ID added and the print removed:
import anthropic profile_id = " uprof_... " # the ID you stored at signup client = anthropic. Anthropic () message = client. messages. create ( model = " claude-opus-5-5 ", max_tokens = 1024, messages = [{ " role ": " user ", " content ": " Hello, Claude " }], user_profile_id = profile_id, ) Enter fullscreen mode Exit fullscreen mode The same header works on token counting, Message Batches and the OpenAI SDK compatibility endpoint ( docs ).
With a profile on each request, a restriction can land on one customer's window instead of the whole building.
1. Creating a profile isn't idempotent. "Every call creates a new profile, even when reference_id matches an existing one" ( docs ). Create it in your onboarding flow, store the uprof_ ID on the customer record, and have every service read it from there. A worker that calls create on startup will mint a new profile per boot.
2. An old beta header hides the ban fields. Responses leave out enforcement_status and enforcement_actions when your anthropic-beta header carries user-profiles-2026-09-04 or an earlier value, and the enforcement_status[] list filter returns a 400 ( webhooks docs ). If you adopted profiles during the beta, remove that value.
3. Bedrock and Google Cloud don't look the profile up. Profiles also work on Claude in Amazon Bedrock and on Claude Models on Google Cloud (Google managed), but you create them on the Claude API or Claude Platform on AWS. Those two platforms check only the ID's format. "They accept any well-formed ID, so a successful response doesn't confirm that the ID matches a profile" ( docs ). On Bedrock, the ID goes in a user_profile_id field in the request body, not a header, and the older InvokeModel and Converse integration doesn't support it at all.
4. On Claude Platform on AWS, the fields always say unrestricted. There, enforcement_status is always unrestricted and the actions list is always empty, and Anthropic doesn't refuse requests there because of an open action ( docs ).
5. You can't clear a field. You can replace a value in external_user_details, but the API rejects null with a 400 ( docs ). If you don't know a customer's country, leave it out rather than sending a placeholder you can never remove.
Each profile now reports enforcement_status as unrestricted, restricted or banned (the API reference also lists pending, while an identity check is under review). "While an action is open, Anthropic refuses some or all inference requests that carry the profile's ID" ( docs ). Each entry in enforcement_actions has a type ( restriction or ban ), a reason such as fraud_or_abuse or account_compromise, an action the customer can take or null, and an expires_at time or null.
The docs also tell you how to handle values they haven't invented yet: treat an unknown enforcement_status as restricted and an unknown reason as unspecified ( docs ). In code, that's one line with a fallback:
KNOWN = { " unrestricted ", " restricted ", " banned " } def effective_status ( raw: str ) -> str: # Anthropic can add values; fail toward caution. return raw if raw in KNOWN else " restricted " Enter fullscreen mode Exit fullscreen mode Knowing a customer is restricted lets your app show them a real message instead of a stream of failed requests, and lets your support team see the reason before the customer opens a ticket.
Anthropic also added organization webhooks in beta, behind the webhooks-2026-10-07 header. They define two events, user_profile.enforcement_action_opened and user_profile.enforcement_action_resolved. To get access, you contact your Anthropic account team ( docs ).
Then comes the note: "Anthropic doesn't send the two events, so an endpoint you register receives nothing" ( docs ). You can build the handler today. You can't rely on it today.
The enforcement webhook is wired to nothing for now. A scheduled check is the doorbell that works.
Even once delivery goes live, the docs describe a webhook you can't treat as the source of truth ( docs ):
Deliveries follow the Standard Webhooks spec, so verify the webhook-signature header with your endpoint's whsec_ secret, and return a 2xx within 5 seconds before doing slow work ( docs ).
Every path above ends at the same call. Anthropic's own catch-up advice is to list your profiles filtered by status ( docs ):
curl -g "https://api.anthropic.com/v1/user_profiles \?enforcement_status[]=restricted&enforcement_status[]=banned" \ -H "x-api-key: $ANTHROPIC_API_KEY " \ -H "anthropic-version: 2023-06-01" Enter fullscreen mode Exit fullscreen mode The -g flag stops curl from treating the brackets as a glob. A page can come back with fewer profiles than limit, or none, before the list ends, so keep requesting pages until next_page is null ( docs ). Also, a status change "doesn't reliably move updated_at," so compare the two enforcement fields with the values you last stored, not the timestamp ( docs ).
Run that on a schedule now. When event delivery goes live, keep the job as the reconciliation pass behind the webhook. The webhook tells you sooner; the scheduled list call catches whatever it repeats, reorders or drops.
Profiles are optional, so a platform that skips them keeps the old risk ( MIXED News ). If you send traffic for other people, creating a profile per customer and sending one header is a cheap way to keep one bad customer's ban from landing on everyone else. Are you creating profiles at signup, or backfilling an existing customer base first?
A ban webhook that can repeat, reorder and drop events is the textbook case for idempotent consumers and a reconciliation job. If you're wiring one up, my Event-Driven Architecture Pocket Guide walks through the event-driven patterns around it: sagas, CQRS, the outbox, and the traps nobody warns you about. It's one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design.
I also build Hermes IDE, a free desktop app for running Claude Code, Codex and other coding agents side by side, each on its own branch: download it or star it on GitHub.