Skip to main content
Atlas exposes one URL prefix per audience, and each prefix has exactly one authentication method, enforced in middleware. A handler never decides its own auth, and credentials never cross surfaces.
PrefixAudienceAuth
/api/v1/*External developers (REST)API key
/api/mcpAI agents (JSON-RPC 2.0 / MCP)API key
/api/signer/*Document recipients (no account)HMAC envelope token
/api/auth/*The Atlas web app (sessions)Better Auth
/api/healthLiveness probesNone
/api/openapi.jsonDocs toolingNone

​
API keys

API keys authenticate the REST API (/api/v1) and the MCP server (/api/mcp). Create and revoke them from the dashboard; each key is shown in full exactly once, at creation. Pass the key as a bearer token: 
curl https://api-atlaswork.vercel.app/api/v1/ping \
  -H "Authorization: Bearer $ATLAS_API_KEY"
The x-api-key header is also accepted: 
curl https://api-atlaswork.vercel.app/api/v1/ping \
  -H "x-api-key: $ATLAS_API_KEY"
Treat API keys as secrets. They are server-side credentials — never ship them in client-side code or commit them to source control. Each key is rate-limited and carries per-key usage visibility (last used) in the dashboard.

​
Signer tokens

Recipients sign without ever creating an account. Each signing link carries a stateless, HMAC-signed envelope token scoped to a single envelope (and optionally a single signer, with an expiry). A valid signature proves Atlas minted the token. You never construct signer tokens yourself — Atlas issues them in the emailed links. The /api/signer/* surface accepts the token as a bearer token or a token query parameter, and is the only surface with CORS enabled (limited to the apex web origin).
Least-privilege links: every emailed link authorizes exactly one person to do exactly one thing on exactly one envelope. A signer’s link can never expose another participant’s fields or a different envelope.

​
Errors

Authentication failures use the standard error envelope (see Errors): 
{ "code": "unauthorized", "message": "Missing or invalid API key" }