Authentication

Authenticate REST requests and understand Tenant resolution.

Overview

Send one Authorization: Bearer <credential> header with every request. The credential tells Blazing Agents which tenant you are, and every request can reach only that tenant's data. Attribution fields such as userId group your data by end user; they do not narrow what an API key can access.

Credentials

CredentialIntended callerHow it is checked
ba_ API keyYour backendMatched against your keys; the full key is shown only once, at creation
Dashboard JWTBlazing Agents dashboardVerified as a signed-in dashboard session for an existing tenant

Create API keys at https://www.blazingagents.com/app/keys. Never give either credential to end-user clients.

Authorization header

curl "$BLAZING_AGENTS_BASE_URL/v1/agents" \
  --header "Authorization: Bearer $BLAZING_AGENTS_API_KEY"

Send the header once. Blazing Agents recognizes the credential type from its shape. There are no scopes, per-agent permissions, or extra auth headers.

Tenant resolution

An API key always belongs to one tenant. A dashboard JWT works only after the signed-in user's tenant exists; signing in with OAuth alone does not create one. Every endpoint in this reference accepts either credential. A few dashboard-only endpoints, such as API key management and MCP OAuth approval, accept only a dashboard JWT because they check which administrator is signed in; they are not part of this reference.

Authentication failures

StatusCodeMeaning
401unauthorizedHeader missing, malformed, expired, invalid, or unknown; also returned when an API key calls GET /v1/me
404not_foundValid JWT, but the signed-in user has no tenant yet

See the complete error contract.

Secret handling

You see the full API key only once, when you create it. Store it in a backend secret manager and never log it. To rotate, create the replacement before you delete the old key. Use a separate key per environment when that helps you operate.

Next

On this page