Claude API user profiles can restrict one customer, not your whole org, but webhooks stay dark

What Anthropic shipped

On October 20, Anthropic introduced user profiles for the Claude API, a mechanism that lets a platform attach an identity to each request it forwards so that safety enforcement can target a single end customer rather than the organization holding the API key. A day later, according to a writeup on dev.to, the company added fields that expose enforcement state on those profiles.

The change addresses a structural risk for anyone reselling or embedding Claude. Until now, a SaaS app, gateway or reseller sent all customer traffic under one organization, and Anthropic's own documentation acknowledged that one misbehaving end customer could trigger enforcement against the entire organization, taking every other customer down with it.

How profiles work

A platform creates one profile per end customer through a dedicated endpoint and receives an identifier prefixed with uprof_. That identifier travels with every request made on the customer's behalf, either via the anthropic-user-profile-id header or as an SDK argument. Anthropic's docs, as relayed by the source, say profiles are free, contain no conversation content, and that the submitted details are not verified.

There are two kinds. Application profiles, the default, fit users of your own product. Passthrough profiles are meant for companies you resell access to, with one profile per company rather than per employee. Requests sent without a profile ID count as the platform's own usage, and Anthropic suggests isolating that traffic in a separate organization because profiles belong to an organization, not a workspace. The identifier also works on token counting, message batches, and the OpenAI SDK compatibility endpoint.

Details that can bite

The dev.to writeup lists five pitfalls. Profile creation is not idempotent: every call produces a new profile even when the reference identifier matches an existing one, so the ID should be minted once during onboarding and stored. Responses omit the enforcement fields, and the status filter returns a 400, if a request still carries a beta header set to user-profiles-2026-09-04 or earlier. On Amazon Bedrock and Google Cloud's managed Claude, only the ID's format is checked, so a well-formed but nonexistent ID is accepted; Bedrock's older InvokeModel and Converse paths do not support profiles at all, and there the ID goes in the request body rather than a header. On Claude Platform on AWS, enforcement status always reads unrestricted and requests are never refused because of an open action. Finally, fields can be replaced but never cleared, since null values fail with a 400, making placeholders permanent.

Reading and reacting to enforcement

Each profile reports a status of unrestricted, restricted or banned, with a pending value documented while an identity check is under review. Actions carry a type, a reason such as fraud_or_abuse or account_compromise, an optional instruction for the customer, and an optional expiry time. While an action is open, Anthropic refuses some or all inference for that profile ID, leaving other traffic untouched. The docs also advise failing safe: treat any unknown status as restricted and any unknown reason as unspecified.

A webhook that stays quiet

Anthropic also opened organization webhooks in beta, behind the webhooks-2026-10-07 header, defining events for enforcement actions opening and resolving, with access granted through an account team. The catch is that delivery is not active: endpoints can be registered today but receive nothing, so the practical path is polling the profile list filtered by enforcement status, paginating until the end, and diffing the enforcement fields, since a status change does not reliably update the record's timestamp.

Even once delivery goes live, the docs caution that events carry only IDs, can arrive more than once, late or out of order, are retried briefly and then dropped, and never fire for actions opened before registration or for actions closed by profile deletion. Deliveries follow the Standard Webhooks spec, so endpoints must verify signatures and answer with a 2xx quickly.

Why it matters

Shared-key architectures made platforms collectively liable for their worst customer. Per-customer profiles move enforcement to the right granularity, which is close to a prerequisite for running production agents across many tenants. Until webhook delivery is switched on, and given the uneven enforcement reporting on AWS-hosted Claude, teams should treat polling as the source of truth and surface restriction reasons in their own product rather than letting customer requests fail opaquely.