Authentication
Two auth methods, one product surface. SDKs and CI integrations use API keys; the dashboard at app.davaengine.ai uses cookie sessions.
Pick the right method
| Auth | When | What to send |
|---|---|---|
| API key | SDKs, CLI, CI, server-to-server | Authorization: Bearer dava_live_… |
| Cookie session | Browser dashboard at app.davaengine.ai | Cookie: dava_session=… |
Both methods land at the same routes under /v1/<product>/*. CSRF protection is only enforced on cookie-authenticated requests; API-key requests skip CSRF since the bearer token itself is the proof of authenticity. Don't mix the two on the same request.
API keys
Mint keys at app.davaengine.ai/admin/keys. The plaintext is shown once on creation — store it in your secret manager and never commit it. The prefix dava_live_ + the last 4 chars are kept on the row for display; the full key is Argon2id-hashed and a SHA-256 lookup hash is indexed for O(1) auth.
bashcurl https://api.davaengine.ai/v1/connect/jobs \
-H "Authorization: Bearer dava_live_<your-key>" \
-X POST \
-H "Content-Type: application/json" \
-d '{"file_ids": ["…", "…"]}'Revocation
Revoke a key from the same admin page. Revocation is immediate — the next request returns 401 invalid_api_key. Issue a new key, deploy it, revoke the old one. There's no overlap window enforced server-side.
Cookie sessions
Sessions are HTTP-only cookies issued by POST /auth/login; CSRF is enforced via an X-CSRF-Token header that the dashboard reads from GET /auth/me on mount. The dashboard handles all of this for you — you almost certainly don't need to touch /auth/* directly unless you're building a custom admin client.
Per-product entitlements
Even with valid auth, a request to /v1/<product>/* 403s with forbidden_entitlement_missing if the org isn't provisioned for that product. AVA staff bypass is suppressed during impersonation so support sees what the customer would see.
For self-host installs, an additional license JWT gate runs first — see self-host.