Claude adds customer level API enforcement and beta webhooks
Anthropic announced user profiles and beta organization webhooks in its October 20, 2026 release notes. Platforms, gateways and API resellers can identify the customer behind a request, allowing safety enforcement to apply to that customer. The accompanying webhooks notify operators when restrictions or bans begin and end. October 20 release notes.
The SDK and ant command line tool support the profile endpoints. Webhooks require the webhooks-2026-10-07 beta header and access through an Anthropic account team. That date is a version identifier, not the announcement date. These additions concern API operations. They do not announce a new Claude model.
Match the profile to the customer
The profile guide distinguishes an application user from a company buying API access through a reseller. Register the appropriate customer once, retain the returned identifier and attach it to subsequent requests. Creation is not idempotent. Repeating it produces another profile. Profiles cost nothing and contain supplied customer details, rather than conversation content. User profile guide.
Profiles belong to an organization across its workspaces. Anthropic recommends separate organizations for internal usage and customer traffic. Management is available through the Claude API, Claude Platform on AWS and Microsoft Foundry deployments hosted by Anthropic, excluding Azure hosted deployments.
Google Cloud and the newer Claude in Amazon Bedrock integration can attribute inference to profiles created elsewhere. Legacy Bedrock InvokeModel and Converse calls cannot. The guide says Google Cloud and the supported Bedrock integration check identifier format without looking up the profile. A successful response there does not verify that attribution points to a real profile.
Notifications have narrower availability
Organization webhooks are a Claude API beta. Organizations need access enabled and cannot have HIPAA readiness enabled. A default workspace using a customer managed encryption key also prevents availability. Events contain profile and enforcement action identifiers. Applications retrieve the profile for its current state because notifications may arrive late or out of order. Organization webhook guide.
Receivers must verify Standard Webhooks signatures. They must return a successful HTTP response within five seconds, then handle slower work separately. Duplicate events require deduplication. Failed deliveries receive limited retries before being dropped, and missed events are not replayed after an endpoint is enabled again. Listing profiles by enforcement status provides a reconciliation route.
An organization can register 32 endpoints, including disabled ones. Delivery URLs require a public domain and HTTPS on port 443. Replacing a signing secret invalidates the old one immediately. Retries then use the replacement too. Only administrators, owners and primary owners can change endpoints or replace their secrets.
Plan the rollout around evidence
Our implementation recommendation is to assign ownership of the customer to profile mapping and notification receiver before expanding deployment. Review how records are matched, how operators investigate a notification and how recovery is checked after an interruption. Those responsibilities should be explicit even in a small pilot.
ByteForward reviewed the public documentation without creating profiles, configuring webhooks or testing delivery. The release date establishes the announcement, not an independently verified activation time for every account. A production trial should establish what the selected deployment actually supports before the team relies on it.
For related operational context, see ByteForward’s guide to Claude Platform tracing.
Illustrative network equipment photograph by Raysonho @ Open Grid Scheduler / Grid Engine (2011), via Wikimedia Commons, CC0.
