Admin API

Purpose and Scope

The Admin API is the organization-administration surface for Claude Platform. It is used when an integration needs to manage resources that normally live in the Claude Console, such as organization information, organization members, workspaces, invites, API keys, and reporting-oriented resources. The official docs explicitly distinguish this from individual-account usage: the Admin API is for organizations, and administrative credentials are required before calls can succeed. Treat this page as the SDK-oriented orientation layer: it explains what the Admin API is for, which credentials are accepted, what endpoint families matter, and what repository-level runtime constraints apply when calling these endpoints from TypeScript or JavaScript applications.

The TypeScript SDK repository is generated from Anthropic OpenAPI definitions, but the requested source evidence for this page is intentionally focused on runtime and platform mechanics. That matters for Admin API work because administrative automation is commonly run from CI jobs, backend services, scheduled scripts, and internal tooling. The SDK’s internal platform detector records the JavaScript runtime and package version in Stainless metadata headers, while the repository’s contributor guidance requires runtime-agnostic source modules unless code is explicitly isolated as Node-only. Those constraints shape where Admin automation should run and how to avoid accidentally exposing organization-level credentials in browser bundles.

Sources: src/internal/detect-platform.ts, CLAUDE.md

Relevant Source Files

• src/internal/detect-platform.ts — Detects Node.js, Deno, Vercel Edge Runtime, browser user agents, and unknown runtimes, then builds X-Stainless-* platform properties such as language, package version, operating system, architecture, runtime, and runtime version. This is relevant to Admin API callers because administrative requests should be made from controlled server-side or automation runtimes, and the SDK records runtime metadata consistently across those environments.
• CLAUDE.md — Defines repository rules for Node-only code. It explains that code referencing Node built-ins must live in a node.ts module or node/ directory, that SDK-internal code should avoid importing Node-only modules, and that browser shims must preserve export surfaces when unavoidable. This is relevant to Admin API integrations because credential-bearing administrative code should be explicit about runtime boundaries and bundler behavior.

Admin API Model

The Admin API uses standard HTTP resources under organization-oriented paths. The official API reference begins with GET /v1/organizations/me, which returns an organization object with id, name, and type, where type is always organization. That endpoint is a useful smoke test for credentials because it does not mutate state and confirms which organization the credential belongs to. The docs then expand into administrative families such as invites, users, workspaces, workspace membership, API keys, usage and cost reporting, rate limit reporting, and related governance APIs.

Authentication is the first design decision. The official docs describe two accepted credential forms for the Admin API: an Admin API key beginning with sk-ant-admin... sent in the x-api-key header, or an OAuth bearer token with the org:admin scope sent in the authorization: Bearer header. Admin API keys can be provisioned only by organization members with the admin role. OAuth org:admin tokens can be obtained only by members with the admin, owner, or primary owner role. Because both credential forms can affect organization-wide resources, they should be treated as high-sensitivity secrets and kept out of browser-delivered code.

The Admin API key documentation also clarifies that a single Admin API key authenticates the broader Admin documentation family. You do not need a different key for each administrative API area. In practice, that means a platform team can issue one properly scoped administrative credential for automation that handles organization administration, analytics, compliance, spend limits, usage and cost, and rate limit reporting, subject to the product and organization type. Rotate those credentials like other privileged secrets, and prefer dedicated automation credentials over sharing a human user’s token in scripts.

Claude Platform on AWS has an important availability exception. The official docs state that most Admin API endpoints are not available there, but workspace endpoints on /v1/organizations/workspaces are available for create, get, list, update, and archive. Other endpoint families, including organization members, workspace members, invites, API keys, usage reports, cost reports, and rate limit reports, are not available on that platform. If you are writing a multi-platform administrative tool, separate workspace-management flows from broader organization-governance flows and make the platform limitation visible in configuration or deployment documentation.

System-to-Code Mapping

The repository source included for this page does not define the public Admin endpoint list; that endpoint taxonomy comes from the official Claude documentation. The source does, however, show how the TypeScript SDK identifies the runtime that will execute those HTTP requests. src/internal/detect-platform.ts checks for Deno first, then Vercel Edge Runtime, then Node.js by inspecting globalThis.process, and finally browser user-agent information. It normalizes the result into Stainless metadata headers including X-Stainless-Lang, X-Stainless-Package-Version, X-Stainless-OS, X-Stainless-Arch, X-Stainless-Runtime, and X-Stainless-Runtime-Version.

Sources: src/internal/detect-platform.ts

That platform metadata is not an Admin-specific authorization mechanism; it is SDK infrastructure that helps Anthropic understand client runtime characteristics. For Admin API users, the practical lesson is that administrative scripts can run in more than one supported JavaScript environment, but credential placement remains the caller’s responsibility. A Node.js script running in CI, a Deno automation job, or a server-side edge function can all be plausible places to call organization endpoints. A browser application is usually the wrong place because it would expose Admin API keys or OAuth admin tokens to end users.

CLAUDE.md reinforces this separation at the repository-maintenance level. The project avoids accidental coupling to Node built-ins in runtime-agnostic modules because bundlers follow statically resolvable imports, including lazy relative imports, and can fail browser builds when node: built-ins appear in bundled chunks. The guidance requires Node-only code to live in explicitly named Node modules, strongly prefers user-provided Node-only modules over SDK-internal imports, and requires browser shims when internal references are unavoidable. Admin integrations should follow the same spirit: put privileged filesystem, environment-variable, secret-manager, or CI-specific logic in server-only modules, not in reusable browser-facing packages.

Sources: CLAUDE.md

Authentication and Execution Flow

A safe Admin API workflow starts by deciding which credential form your organization supports. If you use an Admin API key, store it in a secret manager or deployment environment variable and send it as x-api-key. If you use OAuth, ensure the token has the org:admin scope and send it as authorization: Bearer. In both cases, include the API version header expected by the Claude API, such as anthropic-version: 2023-06-01 in the official examples. Then begin with a read-only organization call before making mutations.

A minimal credential check is conceptually simple: call GET /v1/organizations/me, verify the returned organization ID and name, and log only non-secret identifiers. After that, add the administrative operation you need, such as creating an invite with POST /v1/organizations/invites or listing workspaces. For scripts that run repeatedly, make idempotency explicit at the application layer: check whether a user, workspace, or invite already exists before attempting creation, and handle deleted, expired, pending, or accepted invite states deliberately. Administrative automation should be predictable because mistakes can affect teammates, access, and cost controls.

The official invite example shows that invite creation requires an email and a role, and that the role cannot be admin. Returned invite objects include fields such as id, email, expires_at, invited_at, role, status, and type. This pattern is representative of the Admin API: request bodies are structured, responses include typed objects, and status fields are important for reconciliation. When integrating from TypeScript, model those response states explicitly rather than treating all successful responses as interchangeable strings.

For workspace automation, design your tool around the product surface you actually deploy to. On the standard Claude Platform, workspace administration can be part of a larger governance workflow involving organization membership, API keys, and reporting. On Claude Platform on AWS, the official docs limit availability to workspace endpoints, so a tool that assumes invite, key, or report APIs exist will fail by design. A good CLI or service should expose this as a mode or capability check rather than as a surprising runtime error after a privileged operation has already started.

Compact Reference

Example request shape from the official docs, shown here as an HTTP-level reference rather than a repository source contract:

curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/me" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

When adapting this into a TypeScript project, keep the credential source environment-specific and server-side. If a script reads from process.env, that script should live in a Node-only execution path or be invoked by infrastructure that guarantees the secret never reaches a browser build. If a shared package contains Admin helper functions, pass credentials or preconfigured clients in from the application boundary rather than importing Node-only secret-loading code into a runtime-agnostic module. That approach aligns with the repository’s bundling guidance and makes security reviews simpler.

Operational Guidance and Next Steps

Admin API integrations should be reviewed as platform administration tools, not ordinary end-user features. Start with read-only endpoints, add explicit confirmation or dry-run modes for mutations, and log resource IDs without logging credentials. Keep role mappings close to the code that creates invites or memberships, because organization roles such as billing, Claude Code user, developer, and user have different operational meanings. If your organization uses OAuth-based administration, document how org:admin tokens are obtained and refreshed; if it uses Admin API keys, document who can create and rotate them.

From the SDK repository perspective, the main implementation concern is runtime hygiene. The detector in src/internal/detect-platform.ts shows that the SDK can characterize multiple runtimes, while CLAUDE.md shows the project’s expectations for isolating Node-only behavior. Use those constraints when deciding where Admin automation belongs. For most teams, the best next step is a small server-side script that verifies GET /v1/organizations/me, then adds one carefully scoped administrative task, such as workspace listing or invite reconciliation. After that, read the related pages for organization resources, workload identity federation, request options, and runtime support.