Anthropic has added customer-level restriction records to the Claude API. An API gateway—the service forwarding many customers’ model requests under a shared account—can use the October 20–21 releases to register an end customer, attach the profile to requests and inspect the restrictions Anthropic reports for that customer. The new fields are present in the released anthropics/anthropic-sdk-python v2.1.0.
That matters when a provider action interrupts somebody’s work. An operator can investigate a customer record instead of treating every failure as a problem with the shared organization. Anthropic says attribution can let an action apply to one customer while other traffic continues. The public interface makes that boundary inspectable; it does not establish how often enforcement stays within it.
One organization. Separate customer records.
Illustrative records, not live customer data. Compare the reported fields for two customers on two platforms. These are separate examples, not a profile moving between organizations.
One platform organization
Customer A
Request carries profile A
Customer B
Request carries profile B
Customer A · Claude API
Reported status
restricted
Open actions
One hypothetical restriction
In this illustrated Claude API record, the restriction is attached to Customer A’s profile. Customer B has a separate profile. This does not guarantee that an organization-wide action cannot occur.
Customer B’s sample has no open action. On Claude Platform on AWS, both fields instead remain unrestricted and empty: they do not report these actions, and open actions do not cause refusals there. That response is not a clearance signal.
Read the platform-specific contract. The diagram shows record lookup, not the provider’s private classification system.
The new part is the view into enforcement
Profiles already existed in the earlier beta SDK. The October 20 general release was followed the next day by status, action details and a filter for listing affected profiles. This is a released client interface around an existing attribution system, rather than evidence that targeted enforcement began this week.
A profile is a record for someone the platform serves. It can identify a user of an application or a company buying resold access. The response model keeps the platform’s supplied customer details distinct from Anthropic’s enforcement fields. That gives operators two different facts to reconcile: their own account decision and the provider’s current restriction.
A status page needs more than a timestamp
The SDK exposes a practical trap for anyone building that view: updated_at does not reliably advance when reported status changes. Read the status itself. The same response definition includes pending for a qualified identity-check review condition, beyond the three principal states described in the overview. A fixed green/amber/red legend would miss part of the contract.
The filter’s pagination rules matter too. A page can contain no matching profiles and still supply a continuation cursor. Stopping at that empty page can leave affected customers undiscovered. The listing is finished only when next_page is null. Keeping an old profile beta header also leaves out the new fields or rejects the filter.
Organization webhooks offer another route to updates, but remain a beta requiring access from Anthropic’s account team. An event carries identifiers; the consumer retrieves the profile to learn its current state. Delivery can be delayed or out of order, so the latest arriving notification is not necessarily the latest condition.
What an operator can now establish
The client implementation constructs the profile requests and forwards the filter. Its generated tests check methods and response shapes against a configurable test endpoint. We inspected these sources; we did not run the suite or trigger a live restriction. They do not measure classifier quality, reduced collateral bans or uninterrupted service for another customer.
The next useful demonstration is a public gateway integration on a specified platform: customer IDs survive the request path, the operator reconstructs current status after missed notifications, and recovery reaches the right account. The gain this week is concrete. A shared service has a released interface for asking whose restriction it is dealing with—and a clearer contract for interpreting the answer.
