Skip to main content
Sending a bearer token authenticates each API request as one identity, which determines the account, workspace access, and permissions the Registry applies. Do this before any API or SDK management call, locally or in CI. aireg signs in to Atlan Trident on its own and never prints its token, so it cannot supply one for direct API requests; see Use aireg with Atlan.

Before you begin

Before you start, make sure you have:
  • Approved secret store: An ignored local file such as .env.local, a secret manager, or encrypted CI secrets.
  • Target workspace: The workspace you intend to read or write.
1

Get API key

Get a key for the identity the requests should act as:
  • For yourself or a service account: In Atlan Trident, open Settings, select API keys, then New API key, and grant it access to the workspaces it needs. The value is shown once.
  • For an agent: Use the agent’s own key from Settings > Identity on its profile, so its traces and records belong to the agent.
Request only the access the job needs. The credential owner replaces a key that is revoked, expired, or exposed.
2

Store key securely

Load local keys from an ignored .env.local file or a secret manager, and store CI keys in encrypted secrets such as GitHub Actions secrets. Never put a key in a URL, example, log, screenshot, browser local storage, or committed .env file. Rotate it immediately if it appears in source control or build output.
3

Send Authorization header

Send the key on every request:
The gateway verifies it on every documented endpoint. Do not pass tenant identifiers as a substitute for authentication.
4

Verify resolved identity

Call GET /registry/v1/auth/whoami, or client.auth.whoami() in the Identity, and confirm the account it returns. It does not prove access to every workspace or operation, so make a read in the target workspace before any write.

Troubleshooting

For a 401 or 403, see Errors and retries. For a rejected SDK management call, see AtlanAPIError from management call.

Next steps

See also