Authentication
API requests authenticate with a Bearer token issued from your tenant settings. Tokens are scoped per tenant and per role.
Two client types, two credentials: machine calls authenticate with a Bearer token scoped to the tenant, and browser users carry an httpOnly cookie session. This page states the contract for both.
Everything here is enforced server-side — an unauthenticated call never reaches run creation, and a revoked token fails closed.
Credentials live in your tenant, not in shared accounts: every call is attributable to one tenant and one role, which is what keeps results, limits, and audit trails separable between customers.
Bearer token
- Generate from Settings → API keys (admin only).
- Include in every request: `Authorization: Bearer <token>`.
- Tokens are revocable; rotate them at least every 90 days.
Generate tokens from Settings → API keys with an administrator account and treat them like production secrets: scoped, revocable, and rotated on a cycle of at most 90 days. The header is the contract: Authorization: Bearer <token> on every request.
If a token leaks, revoke it from the same Settings → API keys screen where it was created — a revoked token fails closed on the next call. Rotate by creating the replacement first, deploying it, and only then retiring the old value.
Cookie sessions
- The web app uses an httpOnly cookie session for browser users.
- Sessions expire after 7 days of inactivity.
- Same-site policy is `Lax` to prevent CSRF on cross-origin POSTs.
Browser sessions are not a second API credential — they belong to the web app. They expire after 7 days of inactivity and use Same-site Lax, which blocks CSRF on cross-origin POSTs without breaking normal navigation.
Keep the two credentials in their lanes: scripts and CI use the token, people use the browser. Coupling automation to a session cookie ties machine calls to human logouts and breaks both.