Anthropic's Admin API user management endpoints for Claude Enterprise are now generally available

The anthropic-beta: ce-user-management-2026-07-13 header has been retired. Anthropic has graduated the Admin API user management endpoints for Claude Enterprise to general availability, meaning the group and custom role endpoints no longer require that beta flag. Everything that was gated behind it, managing members, invites, groups, and custom roles, is now stable and production-ready.

If your integration was already sending the header, nothing breaks. Anthropic will accept it silently and behave identically. But you no longer need it, and new integrations should omit it.

What was in beta, and what is now GA?

The Admin API for Claude Enterprise organisations lives under https://api.anthropic.com/v1/organizations/. It covers four broad areas:

• Members, list all members, look up a specific member by email, change a member’s role, or remove them.
• Invites, send invites, list pending invites, and withdraw them.
• Groups, create groups, manage group membership, and list groups across the organisation.
• Custom roles, read the custom roles available in the organisation and attach them to groups.

Member and invite endpoints were already available without a beta header. Groups and custom roles were the ones requiring anthropic-beta: ce-user-management-2026-07-13. That requirement is now dropped.

What does this mean for you?

If you are an IT administrator or platform engineer managing a Claude Enterprise organisation, this is the signal that these endpoints are ready for production automation. You can now build reliable pipelines for user lifecycle management without worrying about a beta endpoint being revised or removed underneath you.

Practical things this unlocks include:

• Automating onboarding: when a new hire joins, your HR or identity system can call the invite endpoint to provision them into Claude Enterprise without anyone logging into the admin console.
• Role-based access at scale: create groups that mirror your existing team structure, attach custom roles controlling which Claude features each group can access (chat, Claude Code, web search, connected tools like Slack or Google Drive), and let membership drive access automatically.
• Offboarding: removing a departing employee is a single API call rather than a manual step in the UI.

The important caveat: group and custom role endpoints are specific to Claude Enterprise on claude.ai. They are not available on the Claude Platform on AWS, where only workspace endpoints are supported.

Authentication and scopes

You will need an Admin API key, which starts with sk-ant-admin... and is sent in the x-api-key header. Only organisation members with the admin role can create one. Alternatively, you can use an OAuth bearer token with the org:admin scope if your setup supports it.

Keys are scoped, so you request only the access you need:

• read:members covers member and invite GET endpoints, plus all custom role endpoints.
• write:members covers member and invite POST and DELETE endpoints.
• read:rbac_groups covers group GET endpoints.
• write:rbac_groups covers group POST and DELETE endpoints.
• read:org_audit is a read-only scope for security audit integrations, granting access to every GET endpoint and the Compliance API read endpoints.

One nuance worth knowing: groups are owned at the enterprise level, across the parent organisation and every linked organisation under it. The group scopes therefore require a key created for all linked organisations, not one scoped to a single organisation. The primary owner of the parent organisation can create either type of key.

How custom roles and groups work together

Custom roles define which features a member can access. A custom role is essentially a named set of permissions: grant access to Claude Code, restrict web search, allow a specific connector, and so on. Groups are the container that roles attach to.

The typical workflow is: create custom roles, assign them to groups, then set a member’s role to “Custom”. Once a member’s role is set to Custom, their access is governed entirely by the custom roles attached to the groups they belong to. If they belong to no groups with relevant roles, they have no default permissions.

If a member belongs to multiple groups with different custom roles, permissions are additive. They get the union of all permissions across all roles in their chain. Granting a feature in any role means the member has access to it.

Groups sourced from an identity provider via SCIM carry a source_type of scim. Groups created directly in claude.ai carry direct. The API surfaces this so you can tell programmatically where a group originated.

Rate limits and pagination

The Admin API operates within a shared limit of 100 requests per minute per organisation across all endpoints. Invite creation has a separate limit of 1,200 requests per hour. Exceeding either returns 429 Too Many Requests.

Pagination differs by resource type, which is worth knowing before you build your list-fetching logic. Member and invite lists use ID-based pagination with limit, before_id, and after_id parameters. Group and custom role lists use an opaque cursor via next_page instead.

The broader picture

This GA graduation fits a pattern. Anthropic added groups, custom roles, per-user spend caps, managed Claude Code policies, and a Compliance API for Enterprise organisations in April 2026. The user management API was the beta-gated part of that wave. Retiring the beta header is the natural final step: those capabilities have been tested in production by real enterprise customers and are now considered stable.

For teams that were waiting for GA status before committing to build automation on top of these endpoints, that wait is over.