The Admin API's Rate Limits and Workload Identity Federation

The Claude Admin API's core surface, members, invites, workspaces, and API keys, covers organization management most teams need. Two more endpoint groups exist alongside it, added to the /claude-api skill's own reference material in Claude Code v2.1.247 (26 August 2026): rate limit reporting, and Workload Identity Federation (WIF) management. Both are narrower in audience than the membership endpoints, but each solves a specific, real problem: knowing your actual configured limits without guessing, and letting an automated workload manage its own authentication configuration without a stored long-lived secret.

The Rate Limits API

Anyone running Claude Code, an internal gateway, or a proxy in front of the Claude API eventually needs to know what the organization's actual rate limits are, requests per minute, tokens per minute, per model, per resource. Hardcoding those numbers drifts the moment Anthropic adjusts them or an admin changes a workspace override. The Rate Limits API is the fix: it returns the same numbers shown on the Rate limits page in the Claude Console, programmatically.

Organization-level limits

curl "https://api.anthropic.com/v1/organizations/rate_limits" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

The response is a list of rate limit groups, each covering either a set of model IDs or a non-model resource:

{
  "data": [
    {
      "type": "rate_limit",
      "group_type": "model_group",
      "models": ["claude-opus-5"],
      "limits": [
        { "type": "requests_per_minute", "value": 4000 },
        { "type": "input_tokens_per_minute", "value": 10000000 },
        { "type": "output_tokens_per_minute", "value": 800000 }
      ]
    },
    {
      "type": "rate_limit",
      "group_type": "batch",
      "models": null,
      "limits": [{ "type": "enqueued_batch_requests", "value": 500000 }]
    }
  ],
  "next_page": null
}

Several model versions share one group: an entry might list claude-opus-4-5, its dated ID, claude-opus-4-6, claude-opus-4-7 and claude-opus-4-8 together, since they share the same configured limits. To look up which group a specific model string falls under, either scan the models list yourself or pass it as a query parameter to get only the matching entry back:

curl "https://api.anthropic.com/v1/organizations/rate_limits?model=claude-opus-5" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

An unrecognized model string returns a 404. The model filter only works on the organization endpoint, not the workspace one.

You can also filter by group_type, one of model_group, batch, token_count, files, skills, or web_search, useful when you only care about one resource category and don't want to parse the full list.

Workspace overrides

GET /v1/organizations/workspaces/{workspace_id}/rate_limits returns only the overrides a specific workspace has, not the full set it's subject to. Anything absent from the response is inherited from the organization level rather than unlimited, a distinction worth internalizing before writing anything that reads this endpoint:

• A rate limit group entirely absent from the response has no workspace override; the workspace uses the organization's limit for that group.
• Within a group that is present, a limiter type absent from its limits array has no override for that specific limiter; it inherits the org value too.
• Where a limiter is present, org_limit carries the organization-level value for comparison, or null if the organization has no configured limit for that limiter type at all.

{
  "data": [
    {
      "type": "workspace_rate_limit",
      "group_type": "model_group",
      "models": ["claude-opus-5"],
      "limits": [
        { "type": "requests_per_minute", "value": 1000, "org_limit": 4000 },
        { "type": "input_tokens_per_minute", "value": 500000, "org_limit": 10000000 }
      ]
    }
  ],
  "next_page": null
}

The default workspace can't have overrides at all, so it never appears in this endpoint's response; query the organization endpoint for its effective limits instead. To find a workspace's ID in the first place, use the List Workspaces endpoint or the Console's workspace settings.

What it's for, and what it isn't

Three practical uses stand out: keeping a self-hosted gateway or proxy's own throttling in sync with Anthropic's actual configured limits instead of a value someone typed in once and forgot about; comparing usage data from the Usage and Cost API against configured limits for internal alerting; and auditing that a workspace's overrides match what your provisioning automation expects, useful after any change to workspace configuration.

It's read-only. There's no endpoint here for setting a rate limit; that stays a Console action under a workspace's Rate limits tab. Responses are also currently always a single page (next_page is always null), though it's worth looping on next_page anyway so a client keeps working unchanged if that ever stops being true. Coverage is also scoped to the Messages API and its supporting resources specifically. Claude Managed Agents limits aren't part of this endpoint at all.

Workload Identity Federation

The second endpoint group solves a different problem entirely: how does an automated workload, a GitHub Actions job, a scheduled deployment, a CI pipeline, authenticate to the Claude API without a long-lived API key sitting in a secrets store somewhere, waiting to leak? Workload Identity Federation answers that by letting a workload exchange a short-lived identity token it already has, one its own platform issues, for a short-lived Claude access token, on every run, with nothing long-lived stored anywhere.

The Admin API's WIF endpoints, /v1/organizations/service_accounts, /v1/organizations/federation_issuers, and /v1/organizations/federation_rules, let you manage the three resources that make this work as infrastructure as code, rather than clicking through Console screens by hand each time.

The three resources

Service accounts (svac_...) are the non-human identity a federated token acts as. Creating one is a single call:

curl "https://api.anthropic.com/v1/organizations/service_accounts" \
  -H "authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"name": "inference-worker", "organization_role": "developer"}'

A service account needs a workspace membership before a federated token acting as it can actually do anything: every service account has an implicit membership in your organization's default workspace, and you add explicit memberships elsewhere with GET, POST, and DELETE on /v1/organizations/service_accounts/{service_account_id}/workspaces.

Federation issuers (fdis_...) register an OIDC identity provider, GitHub Actions, an AWS or GCP identity provider, whatever issues the identity tokens your workloads present. The jwks field controls how Anthropic fetches the provider's signing keys, and takes one of three shapes: {"type": "discovery"} when the provider serves the standard /.well-known/openid-configuration endpoint, {"type": "explicit_url", "url": "..."} to point at a JWKS endpoint directly, or {"type": "inline", "keys": [...]} for providers that aren't reachable from the public internet at all.

curl "https://api.anthropic.com/v1/organizations/federation_issuers" \
  -H "authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "name": "github-actions",
    "issuer_url": "https://token.actions.githubusercontent.com",
    "jwks": {"type": "discovery"}
  }'

Federation rules (fdrl_...) are where the mapping actually happens: a rule binds an issuer to a target (typically a service account), with match conditions that decide which of the issuer's tokens qualify. A rule needs a workspace_id or applies_to_all_workspaces: true at creation:

curl "https://api.anthropic.com/v1/organizations/federation_rules" \
  -H "authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "name": "gha-deploy",
    "issuer_id": "fdis_01ABCDEFabcdef0123456789XY",
    "match": {
      "subject_prefix": "repo:my-org/my-repo:ref:refs/heads/main",
      "claims": {"repository_owner": "my-org"}
    },
    "target": {"type": "service_account", "service_account_id": "svac_01ABCDEFabcdef0123456789XY"},
    "workspace_id": "wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ",
    "oauth_scope": "workspace:developer",
    "token_lifetime_seconds": 600
  }'

Get the subject_prefix narrow. It's an exact match unless it ends in *, and a trailing wildcard like repo:my-org/my-repo:* matches every GitHub Actions run against that repository, pull_request runs from forks included, which means anyone able to open a pull request against the repository could mint a token under that rule. Anthropic's own example pins the prefix to a protected branch specifically, repo:my-org/my-repo:ref:refs/heads/main, for exactly this reason.

Bootstrapping a workload to manage its own federation config

There's a deliberate chicken-and-egg gap here worth understanding: the WIF endpoints themselves need an org:admin OAuth token, and granting that scope to a workload is treated as a human decision, not something a workload can request for itself. A rule with oauth_scope: org:admin must target a service account whose organization_role is admin, and creating that specific rule has to happen once, by hand, in the Claude Console under Settings → Workload identity → Connect workload.

Once that one rule exists, though, the workload it's pinned to can manage everything else, further issuers and workspace-scoped rules, through the API itself, without further Console clicking. A workload using one of the SDKs or the ant CLI doesn't perform the token exchange manually; it's configured with federation environment variables (ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, and ANTHROPIC_IDENTITY_TOKEN_FILE or ANTHROPIC_IDENTITY_TOKEN) and the client exchanges the identity token for an access token on its first request, re-exchanging automatically before the token expires. A workload calling the API directly with curl performs that exchange itself and sends the resulting bearer token in the authorization header.

Permissions, constraints and cleanup

An OAuth-authenticated caller can only create or modify federation rules scoped to workspace:developer or workspace:inference. Anything with a more powerful scope, org:admin or workspace:manage_tunnels, has to be created or modified in the Console, the same restriction that makes the bootstrap step a one-time, human action. The same limit applies to updating a federation issuer that backs a rule with one of those more powerful scopes.

Admin API keys don't work on any of these three endpoint groups, for reads or writes; only an org:admin OAuth token authenticates here, which is a real difference from most of the rest of the Admin API, where an Admin API key is the more common credential.

List endpoints accept limit (1 to 100, default 20) and a page cursor from the previous response's next_page field. Archiving any of the three resource types is a soft delete and is idempotent, archiving something already archived just succeeds, but archiving an issuer or service account still referenced by a live federation rule returns a 400; archive the rule first. Pass include_archived=true to a list call to see archived resources, which are hidden by default.

Where this fits with the rest of the Admin API

Rate limits and workload identity federation round out the Admin API surface this site has covered alongside members, invites, workspaces, API keys and Enterprise RBAC. WIF specifically connects to the ant CLI, whose ant auth login --scope "org:admin" flow is how a human administrator obtains the bearer token these endpoints need interactively, and to ant CLI scripting and automation for version-controlling the federation config itself as infrastructure as code once a workload can manage it independently.

Troubleshooting

A federation rule created through the API fails with a permissions error. Check its oauth_scope. An OAuth caller can only create or modify rules scoped to workspace:developer or workspace:inference; anything else, org:admin included, has to be done in the Console.

Admin API key requests to the service-account or federation endpoints return 401. Expected. These three endpoint groups accept only an org:admin OAuth bearer token, never an Admin API key, unlike most of the rest of the Admin API.

A GitHub Actions rule is minting tokens for pull requests I didn't expect. Check whether subject_prefix ends in a wildcard. A trailing * matches every run against the repository, forked pull requests included, not just the branch you intended.

Archiving an issuer or service account fails with a 400. A live federation rule still references it. Archive the rule first, then the issuer or service account.

The rate limits endpoint returns 404 for a model I know exists. Confirm the exact model string, including whether you're passing a dated ID or an alias; an unrecognized string is what triggers the 404, and the endpoint doesn't fuzzy-match.

Where to go next

For the rest of the Admin API's endpoint surface, see the Admin API's user management endpoints. For the underlying rate-limit mechanics these numbers describe, see Anthropic's Rate limits reference. For the CLI that wraps this same authentication flow interactively, see the ant CLI guide. Browse the rest of this site's Claude Platform coverage at getclaudeskills.com/categories.

Verified 29 August 2026 directly against platform.claude.com's Rate Limits API and Manage WIF with the Admin API documentation pages, both read in full, including exact endpoint paths, request and response examples, and the permissions and constraints each page documents.