Skip to main content
Once your Guardian instance is provisioned (see Plans & Access), you reach the API at your dedicated instance URL, where {instance} is your unique instance slug and eu1 is the current environment; both are provided during onboarding:

​
Authentication

Every API request must carry an OAuth2 access token — a signed JSON Web Token (JWT) — in the Authorization header:
You request the token with the client-credentials grant — see Authentication for the token endpoint, audiences, and scopes. Your instance’s audience is its instance name.
API keys are deprecated. Guardian still accepts a long-lived instance key in the x-api-key header, so existing integrations keep working, but new integrations should use an access token. The x-admin-token header has been replaced — administrative endpoints now use the same access token carrying the relevant admin:* scope.

​
Scopes

Each endpoint requires a specific scope. Request only the scopes a given integration needs through the scope parameter when you request a token — follow the principle of least privilege.

​
Token operations

network:tokens:* requires the Network Tokens add-on, and metadata:inquiries:create requires the Metadata Inquiries add-on, enabled on your instance. See Plans & Access.

​
Administrative operations

Administrative endpoints manage the instance itself. They require a token carrying the relevant admin:* scope, and should be issued to operator or back-office clients only.

​
Next steps

API Keys

Manage the deprecated instance API keys that existing integrations still use.