Skip to main content
AgentFlow API requests use bearer-token authentication. Production deployments verify Auth0-issued JWTs directly; local development can opt into DEV_AUTH_BYPASS=true for requests that send no Authorization header.

​
Human requests

Send an Auth0 access token: 
curl -H "Authorization: Bearer $AUTH0_ACCESS_TOKEN" \
  https://api.example.com/api/v1/agents
The token must validate against the deployment’s configured issuer, audience, JWKS, and allowed algorithms. Tenant context is read from the configured namespaced tenant claim or Auth0 /userinfo response.

​
Machine requests

Machine clients use Auth0 client-credentials tokens and must send explicit tenant context headers: 
curl -H "Authorization: Bearer $AUTH0_M2M_ACCESS_TOKEN" \
  -H "snc-tenant: agentflow" \
  -H "snc-userid: svc-agentflow" \
  https://api.example.com/api/v1/agents
The backend verifies the M2M issuer, audience, client-credentials token shape, required scope, tenant claim, and that the token tenant matches snc-tenant.

​
Local development

When the backend runs with: 
DEV_AUTH_BYPASS=true
DEV_TENANT_NAME=agentflow
DEV_USER_ID=local-dev
local requests can omit the bearer token: 
curl http://localhost:8001/api/v1/agents
If an Authorization header is present, the backend verifies it normally.

​
Token contents

The JWT payload includes standard Auth0 fields plus tenant metadata:
ClaimDescription
issAuth0 issuer configured for the deployment.
audAPI audience configured for the deployment.
subUser or machine-client subject.
scope / permissionsOperation scopes; M2M tokens must include the configured required scope when set.
Namespaced tenant claimTenant key used by AgentFlow to select isolated runtime resources.
gty or sub ending in @clientsUsed to identify client-credentials machine tokens.
See Authentication for Auth0 configuration, machine-client headers, SDK profiles, and local development auth.