Authentication & API keys
Part of Production readiness. Pair with API quickstart.
Where credentials are used
| Credential | Header | Use case |
|---|---|---|
| Organization API key | Authorization: Bearer adcrm_live_… | Servers, workers, CI — preferred for automation. |
| Session JWT | Authorization: Bearer eyJ… | After Google OAuth or admin login; same API surface. |
| Admin login JSON | N/A — exchange for JWT | POST /api/v1/auth/login only from trusted scripts. |
Issuance & storage
- Create keys in Dashboard → API keys. The full secret is shown once.
- Store in a secret manager or sealed environment variable — never in frontend bundles, public repos, or support tickets.
- Keys are organization-scoped: they can only access data for that tenant.
Rotation
- Create a new key with a clear name (e.g. include date or system).
- Deploy the new secret; verify traffic with a safe read (e.g.
GET /api/v1/agents). - Revoke the old key via
DELETE /api/v1/api_keys/:id/revoke.
Environments
Use separate organizations or at least separate keys for staging vs production so a leaked non-prod key cannot touch production CRM data.
Field reference — create key
POST /api/v1/api_keys accepts optional name and optional expires_in (integer days). Response includes key (full string once), key_prefix, last_four, expires_at, message reminder to save immediately.