Skip to main content
The Admin API manages the resources that make up your AI Gateway organisation: the integrations that connect model providers, the credentials behind them, the configs and guardrails applied to workspaces, the policies that cap usage, the MCP servers you expose, and the analytics you report on. Anything an administrator sets up in Strata Cloud Manager can be set up here instead. Created in Strata Cloud Manager, the service account is the identity behind every administrative call. It exchanges its credentials for a short-lived token, the token names one tenant, and every request made with it lands on that tenant.
Admin API requests are authorised with a Strata Cloud Manager access token, not a gateway API key. A key that works for inference returns 401 here. See Authentication.

Your first request

1

Create a service account

In Strata Cloud Manager, go to System Settings > Identity & Access, select your tenant, and add an identity of type Service Account. Save the Client ID and Client Secret it issues, and note the tenant service group ID (TSG ID).Full walkthrough with roles and inheritance: Create a service account.
2

Request an access token

Exchange those three values for a token.
3

Call an endpoint

Send the token as a bearer token. Every endpoint takes the same header. Configs belong to a workspace, so name one with workspace_id, the workspace’s UUID.
The response lists the configs in that workspace. You don’t send a tenant identifier, because the token carries it. You do send the workspace, because the token is scoped to the whole organisation. Find a workspace’s ID shows how to get the UUID.
4

Refresh before it expires

Tokens last 15 minutes, reported as expires_in: 900 on the token response. Cache one for that window and refresh it shortly before it lapses.

Base URLs

Which base URL an endpoint uses follows the resource, not the sidebar group it sits in. The organisation guardrail endpoints carry their prefix in the path instead of the base URL, as /admin/v2/guardrails against https://api.apps.paloaltonetworks.com/ai_gw. That resolves to the same place as the admin base above. Each endpoint’s reference page states its server. Where the two disagree, trust the reference page, which is generated from the specification.

How resources are scoped

Every resource sits at one of two levels. Knowing which one you are addressing explains most 403 responses. The split matches the base URLs: organisation-level resources are served from the admin/v2 base. API keys and limit policies span both levels, and POST /api-keys/{sub-type} takes the level from the calling token rather than from the path — sub-type chooses user or service, nothing more. To reach a workspace-level resource, pass workspace_id as a query parameter, on every method, including POST and PUT. It’s required on these calls, and it must be the workspace’s UUID. A workspace slug doesn’t work here.
The Admin API takes an access token, and an access token is scoped to the whole organisation, so it can’t tell the gateway which workspace you mean. A workspace API key already belongs to one workspace, but the Admin API doesn’t accept those keys.

Find a workspace’s ID

The workspace UUID isn’t shown next to the slug in Strata Cloud Manager. Get it either of these ways:
  • From the API. GET /workspaces on the Workspace Service lists the workspaces in your tenant, with the same access token. Filter by name with exact_name, or with name for a case-insensitive substring match. Each workspace’s id is the value to pass as workspace_id.
    The response is shortened here. Workspace names aren’t unique within a tenant, so check total_count before you take the first result.
  • From Strata Cloud Manager. Open the workspace and copy the UUID from the page URL.

Slugs and IDs

Mixing these up is a common cause of 404.
  • Slugs identify the resources you name yourself: /configs/{slug}, /integrations/{slug}, /providers/{slug}
  • IDs identify the resources the gateway names for you: /guardrails/{guardrailId}, /mcp-servers/{mcpServerId}, /policies/usage-limits/{policyUsageLimitsId}, /api-keys/{id}

Guardrails sit at both levels

/guardrails manages the guardrails of a single workspace. /admin/v2/guardrails manages the organisation-wide ones, which apply to every workspace unless a workspace is explicitly excluded. See Enforcing Org Level Guardrails.

Common tasks

Each of these is a sequence of calls, not a single endpoint.
  1. POST /integrations creates the integration and attaches the provider credential
  2. PUT /integrations/{slug}/models chooses which models it exposes
  3. PUT /integrations/{slug}/workspaces grants the workspaces that may use it
Steps 2 and 3 are model provisioning and workspace provisioning. Skip them and the integration exists but nobody can reach it.
  1. POST /mcp-servers registers the server
  2. GET /mcp-servers/{mcpServerId}/capabilities reads the tools it advertises
  3. PUT /mcp-servers/{mcpServerId}/capabilities enables only the tools you intend to expose
  4. PUT /mcp-servers/{mcpServerId}/user-access decides who may call it
  5. POST /mcp-servers/{mcpServerId}/test confirms the connection before anyone depends on it
See the MCP Gateway documentation for what each capability means.
  1. POST /policies/usage-limits defines the budget
  2. GET /policies/usage-limits/{policyUsageLimitsId}/entities shows what the policy currently binds to
  3. PUT /policies/usage-limits/{policyUsageLimitsId}/entities/{entityId}/reset clears consumption for one entity
Rate limits work the same way under /policies/rate-limits. Background in Budget Limits and Rate Limits.
  1. POST /api-keys/{sub-type} creates the key with the scopes it needs, user or service
  2. POST /api-keys/{id}/rotate rotates it on a schedule or on suspicion
Available scopes are listed in API Keys (AuthN and AuthZ).
Tagging requests with metadata is what makes the last one useful.

When a call fails

Every code the Admin API returns is listed on the Errors page.

Audit

Every administrative call is recorded with the principal that made it, the action, the target resource, a timestamp, an IP address and the request details. Automation is attributable to the service account that ran it, which is a good reason to give each one a name that says what it is for.

Next

Authentication

Service accounts, access tokens, and how scope works across a TSG hierarchy

Errors

Every error code, with the usual cause

Audit Logs

The trail of every administrative change

Organisation Management

The same settings, configured from Strata Cloud Manager
Last modified on November 3, 2026