API authentication
Management API requests use an authenticated identity and organization permissions.
Browser sessions and API keys
The dashboard signs in through Google and obtains a short-lived credential for the configured BFF. An expired identity may require signing in again. Email/password sign-in, SAML and automatic token refresh are not advertised capabilities.
Scripts use a Bearer API key against the BFF base URL configured for their installation. Human identities may select a membership with X-Org-ID; API keys remain bound to their own organization. A header cannot grant membership.
Create, store and revoke a key
An owner or admin can create a named key with selected scopes and optional expiry in API keys. The full secret is shown once; store it securely before closing. The backend stores a bcrypt hash and displays only metadata/prefix later.
Create and verify a replacement before revoking an old key. Revoked or expired keys fail authentication when validated. Do not place keys in browser code, URLs, screenshots or logs.
Scopes and roles
API keys require both the current role and the route’s scope. A viewer cannot replay with replay:write. Key management, organization administration, invitations and alerts are not made available to keys merely by assigning a wildcard.
| Scope | Allowed surface |
|---|---|
| webhooks:read | Event metadata, retained content, Live and replay history |
| sources:read | List and inspect sources |
| sources:write | Create, edit, rotate secret and delete sources |
| replay:write | Request replay |
| audit:read | Audit records |
| * | Owner-created wildcard for scoped API actions; does not add human-only administration |
Example
curl "$ACKLANE_BFF_URL/v1/events?limit=20" \
-H "Authorization: Bearer $ACKLANE_API_KEY"Denied access
401 means the identity is absent, expired or invalid; 403 means the action is not permitted. An event or source belonging to another organization returns 404. Content responses use no-store, including failures.