The Claude Admin API's User Management Endpoints

Managing an organization without clicking through the console

Anything you can do to a Claude organization by hand in the Claude Console, invite a teammate, change someone's role, create a workspace, rotate an API key, has a programmatic equivalent in the Admin API. That matters once an organization grows past the size where a human clicking through settings screens is a reasonable way to manage it: onboarding automation, periodic access audits, syncing membership from an external identity system, or provisioning a new workspace as part of a deploy pipeline all become scriptable instead of manual.

This is one part of a broader "Claude API skill" cluster this site has covered as it's expanded through 2026, including what the claude-api skill does, Managed Agents, and the ant CLI. Claude Code's own /claude-api skill was updated in v2.1.247 (26 August 2026) to add Admin API coverage specifically, organization members, invites, workspaces, API keys, rate limit reports, workload identity federation, and CMEK, alongside its existing model-migration and SDK-upgrade material. This guide covers what those endpoints actually do.

Where the Admin API lives, and what it needs

Every Admin API endpoint sits under https://api.anthropic.com/v1/organizations/. Anthropic's own docs are explicit that the Admin API is unavailable for individual accounts: it only applies once you've set up an organization under Console → Settings → Organization.

Three credential types authenticate against it:

• An Admin API key, prefixed sk-ant-admin..., sent in the x-api-key header. Only an organization member with the admin role can provision one.
• An OAuth bearer token with the org:admin scope, sent as an Authorization: Bearer header. Only members with the admin, owner, or primary owner role can obtain one.
• A personal key or service account key not scoped to a specific workspace, also sent as x-api-key, carrying the same permissions as the account it's linked to.

Every request also needs an anthropic-version header, and some entries need an anthropic-beta header for endpoints still in preview.

The endpoint categories

Organizations

A single read endpoint, GET /v1/organizations/me, returns information about the calling organization itself. Available to every organization type.

Users (members)

The core membership surface: list members, look one up by ID, change a role, or remove someone.

curl https://api.anthropic.com/v1/organizations/users/$USER_ID \
    -H 'anthropic-version: 2023-06-01' \
    -H "Authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

{
  "id": "user_01WCz1FkmYMm4gnmykNKUu3Q",
  "added_at": "2024-10-30T23:58:27.427722Z",
  "email": "user@emaildomain.com",
  "name": "Jane Doe",
  "role": "user",
  "type": "user"
}

The role field accepts admin, billing, claude_code_user, developer, managed, membership_admin, owner, primary_owner, or user. Updating a member's role is a POST to the same URL with a new role value in the body; removing a member is a DELETE. These endpoints are available to all organization types.

Invites

POST /v1/organizations/invites creates an invite, GET retrieves or lists them, and DELETE withdraws a pending one. Members and invites use the same endpoints for both Claude Enterprise and Claude Console organizations, though the two organization types behave a little differently under the hood, worth checking against your own org type before scripting bulk invites.

Workspaces

Workspaces are how Claude Console organizations segment usage and spend, and the endpoints cover the full lifecycle: create, retrieve, list, update, and archive a workspace, plus manage its members and, in beta, its service accounts.

curl https://api.anthropic.com/v1/organizations/workspaces \
    -H 'Content-Type: application/json' \
    -H 'anthropic-version: 2023-06-01' \
    -H "Authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
    -d '{
      "name": "Production",
      "data_residency": {
        "workspace_geo": "us",
        "allowed_inference_geos": ["us"],
        "default_inference_geo": "us"
      },
      "tags": {
        "env": "prod",
        "team": "platform"
      }
    }'

A workspace also has its own rate-limit override endpoint, GET /v1/organizations/workspaces/{workspace_id}/rate_limits, useful for confirming a workspace-level cap before diagnosing a rate-limit error elsewhere in your stack.

API keys

The API key endpoints deliberately never return the secret value itself, only metadata: name, status, and enough of a hint to identify which key is which. You can retrieve a key's info, list an organization's keys with filtering, and update a key's name or status (to revoke it, for instance), but you can't recover a lost key's secret through this API; that's by design.

RBAC groups and RBAC roles (Claude Enterprise only)

This is where the endpoint set diverges by organization type. Groups and custom roles exist only for Claude Enterprise:

• RBAC groups: create, list, retrieve, rename, and delete a group, plus manage its membership (GET, POST, DELETE on /rbac_groups/{group_id}/members).
• RBAC roles: list and retrieve roles, and read a role's permission set through /rbac_roles/{role_id}/permissions. The Admin API surfaces roles for reading rather than defining brand-new custom permission sets from scratch through the endpoint itself.

If your organization is on Claude Console rather than Claude Enterprise, these endpoints simply aren't available; role assignment there stops at the fixed set of roles on the User object.

External keys (CMEK), Claude Enterprise only

POST /v1/organizations/external_keys creates a customer-managed encryption key configuration, for organizations bringing their own encryption keys across AWS, GCP, or Azure rather than relying on Anthropic-managed encryption.

What's Enterprise-only vs available everywhere

The practical takeaway: if you're building automation against members, invites, workspaces, or API keys, it works the same whether you're on Console or Enterprise. The moment you need group-based access control or custom roles rather than the fixed role list, that automation only works on Enterprise, and it's worth confirming your organization type before you build a script that assumes RBAC groups exist.

A worked example: onboarding automation

A common use case is syncing organization membership from an external system, an HR tool, an identity provider, rather than inviting people by hand. A minimal onboarding script using the Admin API might:

# 1. Create the invite
curl -s https://api.anthropic.com/v1/organizations/invites \
  -H 'Content-Type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -H "Authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
  -d '{"email": "new.hire@company.com", "role": "user"}'

# 2. On Claude Enterprise, add them to the right RBAC group once accepted
curl -s https://api.anthropic.com/v1/organizations/rbac_groups/$GROUP_ID/members \
  -H 'Content-Type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -H "Authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
  -d "{\"user_id\": \"$NEW_USER_ID\"}"

Pagination on the list endpoints (limit, after_id, before_id) is what makes this practical at scale, since it lets a periodic sync job page through the full membership list rather than assuming it fits in one response, useful for a nightly reconciliation job that compares Claude org membership against your HR system's roster and flags drift in either direction.

Where this fits alongside Claude Code

If you're driving this from inside a Claude Code session rather than scripting it directly, the bundled /claude-api skill is the fastest path in: run /claude-api managed-agents-onboard for the Managed Agents side, or ask Claude directly to work through an Admin API task, since the skill's reference material now explicitly covers members, invites, workspaces, API keys, rate limit reports, workload identity federation, and CMEK as of the v2.1.247 update. For scripting these calls outside a session entirely, the ant CLI wraps the same resource:action pattern the Admin API uses, and its scripting and automation guide covers version-controlling the resources you create this way.

Troubleshooting

A request returns a permissions error even though I have an Admin API key. Confirm the key was actually provisioned by a member with the admin role, and that the specific endpoint you're calling matches your organization type. An RBAC endpoint called against a Claude Console organization fails because the feature doesn't exist there, not because of a permissions problem with your key.

I can't retrieve a lost API key's value. This is expected, not a bug. The API key endpoints only ever return metadata; the secret is shown once at creation and never again. Revoke the key by updating its status and issue a new one instead.

My invite automation is double-inviting people. List pending invites first and check for an existing entry before creating a new one; the invite endpoints don't automatically deduplicate against an email address that already has a pending invite.

RBAC group membership calls return errors on my organization. RBAC groups are Enterprise-only. If your organization is on Claude Console, that entire category of endpoint isn't available, and the fixed role list on the User object is the extent of role-based access you have.

Where to go next

For the wider picture of managing spend rather than membership, see how budgets work across Managed Agents sessions and deployments. For scripting Claude Platform resources generally rather than just admin tasks, see the ant CLI guide. Browse the Claude Platform coverage on this site for the rest of the Claude API and Managed Agents cluster.