On this page · 11 sections
- What the release note said, and what it did not say
- The contradiction in one table
- What this means for a change-freeze or a compliance review
- The parts that will actually break your script
- Roles, seats and the two failure modes that look like bugs
- Which key, and which endpoints that key can reach
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. On 19 August 2026 Anthropic's Claude Platform release notes said the Admin API user-management endpoints for Claude Enterprise organizations were out of beta and that the anthropic-beta: ce-user-management-2026-07-13 header was no longer required. Five days later, on 24 August 2026, the Admin API reference at platform.claude.com/docs/en/api/admin still carries the sentence "For Claude Enterprise organizations, this endpoint's availability is in beta" on 8 separate endpoints: create, get, list and delete Invite, and get, list, update and remove User. Those 8 are every member and invite endpoint the API has. The endpoints that the release note actually cleared of a header requirement, groups and custom roles, carry no beta sentence at all. If you are wiring joiner-mover-leaver automation into a Claude Enterprise tenant, that inversion is the first thing to understand, because it decides what you can put a change-freeze policy behind.
What the release note said, and what it did not say
The 19 August entry is one sentence of substance: the user-management endpoints for Claude Enterprise (claude.ai) organizations, covering members, invites, groups and custom roles, are out of beta, and the ce-user-management-2026-07-13 header is no longer required on group and custom-role requests. Requests that still send it are accepted unchanged.
Read the second clause again. The header was only ever required on group and custom-role requests, and only those requests are named in the removal. Members and invites never took that header. So the header retirement, the concrete part of the announcement, does not touch the 8 endpoints most joiner-mover-leaver scripts call.
The guide page at manage-claude/user-management repeats the narrow version in its own note: "Group and custom-role requests don't require the anthropic-beta: ce-user-management-2026-07-13 beta header. Requests that still send it are accepted and behave identically." It says nothing about members or invites being GA.
Meanwhile the reference page still marks them beta. Both pages are live and both are official. This is not a stale mirror or a cached copy; the two statements sit one click apart in the same documentation set.
One more detail closes the loop. The Beta headers page at platform.claude.com/docs/en/api/beta-headers does not list ce-user-management-2026-07-13 anywhere. The user-management guide links the phrase "beta header" straight to that page, and the header it names is not on it. A reader following the link to check the header's status finds no entry either way.
The contradiction in one table
| Endpoint group | 19 Aug release note | API reference (api/admin) |
Beta header ever required |
|---|---|---|---|
| Members: get, list, update, remove User | Out of beta | "availability is in beta" | No |
| Invites: create, get, list, delete Invite | Out of beta | "availability is in beta" | No |
Groups: 5 rbac_groups endpoints |
Out of beta | No beta marking | Yes, until 19 Aug 2026 |
| Group members: 3 endpoints | Out of beta | No beta marking | Yes, until 19 Aug 2026 |
Custom roles: 3 read-only rbac_roles endpoints |
Out of beta | No beta marking | Yes, until 19 Aug 2026 |
The endpoints that lost a requirement are the ones nobody marked beta. The endpoints still marked beta lost nothing.
There is a small irony inside the same documentation set. The user-management page explains that a custom role can carry a blanket permission whose action is capability_access_all_ga, defined as "every stable product feature, that is, every feature not labeled beta or research preview." An organization that grants that role is granting access to everything except beta features, through an API that its own reference labels beta.
What this means for a change-freeze or a compliance review
For an engineering team the practical question is not semantic. Most enterprises gate production automation on a supported-API rule: no beta dependency in a system that provisions or deprovisions access. Here the answer depends on which page your reviewer opens.
Treat it as the reference page reads. The safe reading of two conflicting official statements is the more restrictive one, and it costs you nothing: the endpoints behave identically either way, because no header ever changed hands. What changes is your paperwork. If your control framework demands a GA citation, cite the 19 August release note and record the reference-page discrepancy in the same control, with the date you checked it. That is defensible. Silently picking the reading you prefer is not.
The one thing not to do is wait for the reference page to catch up before building. Nothing in the request or response shape is pending. The disagreement is editorial.
The parts that will actually break your script
Set the beta question aside and the more expensive problem is that this single API carries two different conventions, split along exactly the members-and-invites versus groups-and-roles line.
Two header rules. Member and invite requests require anthropic-version: 2023-06-01. Group and custom-role requests do not. A shared HTTP client that sets the version header globally is fine; one that sets it conditionally, or a hand-rolled curl in a runbook, will diverge between the two halves.
Two pagination styles. Member and invite lists use ID-based pagination: pass limit, which defaults to 20 and maxes at 1000, plus at most one of before_id or after_id, and page using first_id and last_id until has_more is false. Group and custom-role lists use an opaque cursor instead: pass the response's next_page value back unchanged as the page parameter until next_page is null. Writing one generic paginator for the Admin API produces a loop that silently returns 20 rows and stops.
Two rate limits. Admin API endpoints share a per-organization limit of 100 requests per minute. Invite creation has its own limit of 1,200 requests per hour instead. Over either limit, the API returns 429. An onboarding job that creates 1,200 invites in a burst is inside the hourly invite budget and well outside the per-minute one.
| Behaviour | Members and invites | Groups and custom roles |
|---|---|---|
anthropic-version: 2023-06-01 header |
Required | Not required |
| Pagination | limit (default 20, max 1000), before_id / after_id, has_more |
Opaque cursor: next_page passed as page |
| Write access through the API | Yes, for role changes, removals, invites | Groups yes; custom roles read-only |
| Scopes | read:members, write:members |
read:rbac_groups, write:rbac_groups |
| Marked beta in the API reference | Yes, on all 8 | No |
Roles, seats and the two failure modes that look like bugs
The API returns five organization role values for a Claude Enterprise member: user, managed, owner, membership_admin and primary_owner. There is exactly one primary owner. The API can assign only two of the five, user and managed; the administrative roles are assigned in claude.ai organization settings, and members holding them cannot be modified or removed through the API at all. A deprovisioning script that walks the member list and calls remove will fail on precisely the accounts a leaver process most needs to handle.
Seats are the second trap. Where a plan draws members from a finite pool of purchased seats, a pending invite consumes a seat. The create-invite endpoint takes no seat or tier parameter: the seat is assigned automatically from the lowest tier that has availability. Creating an invite when no seat is free returns a 400 rather than purchasing one. Withdrawing the invite, letting it expire, or removing the member later returns the seat to the pool. Bulk onboarding against a nearly full pool therefore fails partway with a 400 that reads like a validation error and is actually a billing state.
Two more behaviours are worth pinning to a code comment. Groups are owned by the enterprise as a whole rather than by one organization, so the group scopes require a key created for all linked organizations, while the custom-role catalog is per-organization: fetching a role that belongs to a different organization of your enterprise returns 404 for your key. And a group's roles field is null, not [], when role data was temporarily unavailable. Treating null as "no roles attached" turns a transient read failure into a silent permissions decision. Retry instead.
Custom roles themselves are read-only over the API. They are created and edited in claude.ai organization settings; the three rbac_roles endpoints read the catalog and the permissions each role grants, and nothing more. Any plan to define roles as code against this API stops here.
Which key, and which endpoints that key can reach
A Claude Enterprise Admin API key is created by the parent organization's primary owner at claude.ai organization settings, and carries an sk-ant-api01- prefix. An organization owner can create one too, but only carrying Compliance API scopes, and only for their own organization. The scope set is granular: read:members covers member and invite GET endpoints plus all custom-role endpoints, write:members covers member and invite POST and DELETE, read:rbac_groups and write:rbac_groups cover groups, and read:org_audit is a single read-only scope for security-audit integrations that reaches every GET on the user-management page and the Compliance API read endpoints, but not the Spend Limits or Analytics APIs.
The endpoint split by organization type catches teams that read the Console documentation first. Members and invites work for both organization types. Groups, custom roles and the Spend Limits API are Claude Enterprise only. Workspaces, API keys, usage and cost reports and rate-limit endpoints are Claude Console only, and a Claude Enterprise key cannot reach them. If your plan was one key and one script covering both tenancies, it is two scripts.
The role vocabulary differs too. A Console organization accepts user, developer, billing and claude_code_user on invite creation, with admin not assignable through the API. A Claude Enterprise organization accepts user and managed. Same endpoint, same request body shape, different valid enum.
India-specific considerations
Indian enterprises running Claude Enterprise under a Digital Personal Data Protection Act 2023 programme usually need an auditable record of who held access to a processing system and when. The read:org_audit scope is the right instrument: one read-only key, every user-management GET plus the Compliance API read endpoints, no write path. Pair it with the 100 requests-per-minute ceiling when you size a nightly export, and cache the member list rather than re-listing it per record. Note also that the API cannot enumerate access changes made in claude.ai settings by an owner or membership admin, so the group and role catalog is your evidence surface, not the member endpoints alone.
What is still unknown
Anthropic has not published a date for aligning the reference page with the 19 August release note, and the release note itself gives no service-level or deprecation commitment for the member and invite endpoints. There is no changelog entry retiring the "availability is in beta" sentence. Until one appears, a compliance reviewer reading api/admin will see beta, and you should expect to answer for it rather than argue the page is wrong.
FAQ
How eCorpIT can help
eCorpIT builds identity and access automation against enterprise AI platforms, including joiner-mover-leaver pipelines that have to survive split pagination, scoped keys and seat-pool failures like the ones above. We are ISO 27001:2022 certified and CMMI Level 5 assessed, and we design access automation aligned with DPDP Act 2023 evidence requirements. If you are wiring Claude Enterprise into an existing IGA stack, talk to our platform engineering team about the control mapping before you write the first script.
References
Last updated: 24 August 2026.
