# Claude API Adds User Profiles and Beta Enforcement Webhooks

Anthropic gives API platforms end-customer attribution and enforcement notifications, with practical limits around identity, delivery and privacy.

By Paras Madan | 2026-10-21


Anthropic launched Claude API user profiles and beta organization webhooks on October 20, 2026. Together, the additions give platforms a way to identify whose requests they send and learn when Anthropic restricts that customer's access. The [release notes](https://platform.claude.com/docs/en/release-notes/overview) explain the intended benefit: safety enforcement can apply to an end customer rather than the platform's entire organization. That matters when many unrelated customers share one provider account.

## Match profiles to the right customer

The [user profile API reference](https://platform.claude.com/docs/en/api/user_profiles) distinguishes two customer relationships. An application profile represents an individual using a product built on Claude. A passthrough profile represents a company buying resold inference. Application is the default, so gateways reselling access need to choose passthrough deliberately. Messages, token-counting and Message Batches requests can carry the profile ID in the anthropic-user-profile-id header. The profile is a record used for attribution, not a replacement for the application's own authentication system.

## Create profiles once and limit stored data

The [implementation guide](https://platform.claude.com/docs/en/manage-claude/user-profiles) recommends creating each profile once and storing its returned ID on the customer record. Creation is not idempotent: repeating a request with the same reference_id creates another profile. Profiles are not billable. They belong to an organization, not a workspace, and Anthropic recommends separating internal usage from end-customer traffic into different organizations.

Profiles can be created on Claude API, Claude Platform on AWS and Anthropic-hosted Microsoft Foundry deployments, but not Azure-hosted Foundry. Bedrock and Google Cloud attribution use profiles created elsewhere; the older Bedrock InvokeModel and Converse integration does not support them.

Data minimization deserves attention during onboarding. Profiles contain supplied customer details and program information, not conversation content. All supplied fields are optional, and hashes can represent names or email addresses. Hashes enable matching across profiles, so they should not be described as a guarantee of anonymity. Deleting a profile removes submitted information but preserves Anthropic's trust-and-safety records associated with its ID. These are product behaviors to account for when describing data handling to customers.

## Keep platform and provider status separate

The distinction between customer status and provider status also matters. In the API reference, account_status records the platform's own decision, such as suspending an account. It does not change Anthropic's separate program decisions. Likewise, an active program or feature status can indicate approval without proving a capability has been configured. A dashboard that collapses these fields into one green badge would hide decisions that operators may need to investigate separately.

## Handle enforcement events as notifications

The [organization webhook guide](https://platform.claude.com/docs/en/manage-claude/organization-webhooks) describes a narrower beta. Access requires contacting an Anthropic account team and sending the webhooks-2026-10-07 beta header. Organizations with HIPAA readiness enabled are excluded, as are organizations whose default workspace uses customer-managed encryption. The two events report an enforcement action opening or resolving. They carry identifiers, so receivers retrieve the current profile rather than treating event arrival order as authoritative.

Verify Standard Webhooks signatures, deduplicate event IDs and acknowledge within five seconds. Retries last only a few minutes; ultimately failed events are dropped. Events skipped while an endpoint is disabled are not replayed. Reconciliation therefore needs profile listing, including actions that predate registration. Remove older user-profiles beta headers to expose enforcement fields once enforcement is enabled for the organization. Deleting a profile closes its actions without a resolved event.

## Coordinate endpoint and signing-secret changes

The [webhook API reference](https://platform.claude.com/docs/en/api/beta/organization/webhooks) adds endpoint management separately from customer-profile management. Teams can create, retrieve, update or delete organization endpoints and rotate their signing secrets. Rotation invalidates the old secret immediately, and the replacement is returned only in that response. Treat receiver deployment and secret rotation as one coordinated operation rather than assuming an overlap window. Keeping webhook configuration separate from customer records also makes it easier to assign operational ownership.

For a platform rollout, I would first audit where customer identity enters the request path, including batch jobs and retries. Then test duplicate and delayed notifications against the support workflow that explains an access restriction. The useful outcome is an attributable request and a current customer status that operations can act on, without letting a missed notification silently become the source of truth.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain AI launch stories to developers, turning API changes into clear stories about real operational decisions.

[Book a 30-minute call](https://cal.com/paras-madan/30min).