What landed on 26 August 2026
Anthropic's own release notes for 26 August 2026 state it plainly: "We've launched the Admin API in the ant CLI and the Python, TypeScript, C#, Go, Java, PHP, and Ruby SDKs under client.beta.organization." Before this, scripting against the Admin API meant hand-rolled curl requests against /v1/organizations/* endpoints. Now the same functionality is reachable through the ant CLI as ant beta:organization ..., or through a native SDK call, with the CLI and SDKs handling auth headers, pagination and response parsing for you.
Coverage is broad but not total. The same release note lists what's in: "organization info, members, invites, workspaces and workspace members, API keys, rate limits, service accounts, workload identity federation issuers and rules, and customer-managed encryption keys." And it names what's deliberately left out: "Usage and cost reports and the Claude Enterprise user-management and analytics endpoints remain curl-only." If your automation touches those two areas specifically, this update doesn't change anything for you yet.
Calling it from the ant CLI
Every Admin API call under ant follows the CLI's normal resource:action pattern, with the Admin API's resources living under the beta:organization namespace:
ant beta:organization retrieve
That single command returns your organization's info, the simplest possible check that authentication is working. The ant CLI automatically sends whatever beta header a beta:-namespaced resource needs, so there's no separate step to opt into the Admin API's beta surface the way a raw curl request would need one.
Calling it from an SDK
The same operation in Python and TypeScript, using the pattern every one of the seven supported SDKs follows:
client = anthropic.Anthropic()
organization = client.beta.organization.retrieve()
print(f"id: {organization.id}")
print(f"name: {organization.name}")
const client = new Anthropic();
const organization = await client.beta.organization.retrieve();
console.log(`id: ${organization.id}`);
console.log(`name: ${organization.name}`);
Every method under client.beta.organization maps to one Admin API endpoint. List methods in Python, TypeScript, C#, Go and Java return an iterator that fetches more pages on demand, so a limit argument sets the page size rather than a hard cap on total results. PHP, Ruby and raw curl calls return one page at a time and need manual pagination. In the ant CLI, --limit caps results the same way on the member, invite, workspace, workspace-member and API-key list commands.
Authenticating an Admin API call
Three credential types work, and which one you need depends on what you're calling.
Admin API key. Starts with sk-ant-admin..., sent in the x-api-key header. Only an organization member with the admin role can provision one. This covers most endpoints, but not service accounts, federation issuers or federation rules.
org:admin OAuth bearer token. Required for the three endpoint groups an Admin API key can't reach: service accounts, federation issuers, and federation rules. Obtainable only by members with the admin, owner or primary owner role. The recommended flow logs in through a dedicated ant CLI profile and exports the resulting token for the rest of the shell session:
ant auth login --profile admin --scope "org:admin"
export ANTHROPIC_AUTH_TOKEN=$(ant auth print-credentials --profile admin --access-token)
Anthropic's own guidance here is specific: use a shell you reserve for administration, unset the variable when you're done, and switch the CLI's active profile back with ant profile activate default afterward. The exported token applies to every SDK and CLI call made in that shell for as long as it's set, which is exactly why it's worth confining to a dedicated session rather than your everyday terminal. Interactive tokens are short-lived; if calls start returning 401, re-run the export to refresh it.
Personal or service account key. Not scoped to a specific workspace, sent in x-api-key the same way an Admin API key is, and carries the same permissions as the account it's linked to.
Both the SDKs and the ant CLI read credentials from environment variables automatically: an Admin API key from ANTHROPIC_API_KEY, or an OAuth bearer token from ANTHROPIC_AUTH_TOKEN. Leave ANTHROPIC_API_KEY unset in a shell where you've exported ANTHROPIC_AUTH_TOKEN, so the OAuth token is what actually gets sent.
Automated workloads: skip the login entirely
For CI and other non-interactive automation, Anthropic's documentation recommends against the interactive login flow above entirely. Instead, a workload authenticates through Workload Identity Federation, and the SDKs and CLI perform the token exchange directly from the federation environment variables in that environment, no stored long-lived credential and no human login step at all. This is the same WIF mechanism covered in The Admin API's rate limit reports and workload identity federation endpoints, and it's the piece that makes Admin API automation genuinely CI-friendly rather than dependent on a token someone exported by hand and might forget to rotate.
An org:admin token, however it was obtained, grants access to the entire organization regardless of which workspace the underlying profile or federation rule is bound to. That's worth remembering when deciding which credential a given automation job actually needs: reach for an Admin API key first if the job doesn't touch service accounts or federation, since it's scoped more narrowly by design.
What still means curl
Two categories stay outside ant and the SDKs even after this update, per Anthropic's own release note:
- Usage and cost reports, tracked through the separate Usage and Cost API.
- Claude Enterprise user-management and analytics endpoints, covered in The Admin API's user-management endpoints for Claude Enterprise.
If your scripting touches either of those specifically, this release doesn't remove the need for hand-written curl requests. Everything else the Admin API covers, organization info, members, invites, workspaces, workspace members, API keys, rate limits, service accounts, and workload identity federation, now has a CLI command and an SDK method behind it.
A worked example: reshaping the organization info response
Putting the CLI pattern together with the transform mechanic covered in ant CLI scripting and automation, here's the same organization lookup from earlier, filtered down to just the fields worth seeing with a GJSON transform instead of the full response:
ant beta:organization retrieve \
--transform "{id,name}" \
--raw-output
That's the one Admin API command this article can confirm the exact CLI syntax for, since it's the only one Anthropic's own documentation shows verbatim end to end. The ant CLI's general convention, confirmed on its scripting and command-reference pages, is that nested resources chain with colons (beta:sessions:events, for example), and Anthropic's own release note confirms client.beta.organization exposes members, invites, workspaces and workspace members, API keys, rate limits, service accounts, and federation issuers and rules as SDK methods under that namespace. For the exact CLI subcommand name and flags for any one of those, resource groups beyond organization info itself, run ant beta:organization --help, or the SDK's own client.beta.organization autocomplete: this article won't guess at a specific subcommand spelling that wasn't shown directly in what was fetched.
What each resource covers, and where coverage stops
The Admin API's coverage under this update spans organization info, members and their roles, invites, workspaces and workspace members, API keys, rate limits, service accounts, workload identity federation issuers and rules, and customer-managed encryption keys (the external-key endpoints). Of those, only the service-account, federation-issuer and federation-rule groups require the org:admin OAuth token specifically; everything else accepts an Admin API key too.
Customer-managed encryption keys are also the one resource group with a documented gap on Claude Platform on AWS: only the workspace endpoints and the external-key endpoints are available there at all. Organization members, workspace members, invites, API keys, and the usage, cost and rate-limit reports don't apply to a Claude Platform on AWS deployment, regardless of whether you're calling them through curl, ant, or an SDK.
Why script this instead of using the Console
Everything the Admin API covers is also reachable by hand in the Claude Console. Scripting it earns its keep in three situations specifically: onboarding automation that provisions a new hire's workspace membership and API key the moment an HR system fires a webhook, drift detection that periodically diffs your organization's actual member list and rate limits against a version-controlled expectation, and offboarding that revokes access the moment someone leaves rather than waiting for someone to remember the Console has a page for that. All three are the kind of task that's tedious and error-prone by hand and mechanical once it's a script, which is exactly the gap ant beta:organization and client.beta.organization close: before 26 August 2026, building any of them meant writing and maintaining your own thin curl wrapper around the Admin API's HTTP surface, doing your own pagination and auth-header handling. Now that wrapper is already written.
Troubleshooting
A beta:organization command returns 401. Check which credential is actually active in the shell. If both ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN are set, confirm which one the CLI is reading, and unset whichever one you don't intend to use. An OAuth token obtained through ant auth login --scope "org:admin" is also short-lived; if it worked earlier in the session and now fails, re-export it with ant auth print-credentials.
A service-account or federation command returns 403 even though other Admin API calls work. This is the credential mismatch covered above: an Admin API key can't reach service accounts, federation issuers, or federation rules, no matter what role provisioned it. Those three resource groups accept only an org:admin OAuth bearer token.
A command works in curl but the equivalent ant or SDK call errors as unsupported. Confirm the endpoint isn't one of the two carve-outs, usage and cost reports, or the Claude Enterprise user-management and analytics endpoints. Both are real gaps as of this release, not a bug in your invocation.
Automation running under Workload Identity Federation gets an auth error a logged-in session doesn't. Check the federation environment variables the workload relies on for the token exchange, rather than assuming the problem is the Admin API call itself. WIF authentication happens as a separate step before the request goes out, and a misconfigured federation rule fails there, not at the Admin API endpoint.
Where to go next
For the full Admin API surface and what it covers on Claude Enterprise specifically, see The Admin API's User-Management Endpoints for Claude Enterprise. For Workload Identity Federation and the rate-limit reporting endpoints, see The Admin API's Rate Limit Reports and Workload Identity Federation Endpoints. For the ant CLI itself, start with Anthropic's ant CLI: The Command Line for the Claude Platform and ant CLI Scripting and Automation. Browse the current skill catalog at getclaudeskills.com/skills.
