Authentication
Bearer-token auth on the Authorization header. Workspace-scoped, hashed at rest, scope-checked per request.
The header
Authorization: Bearer ln_live_...Keys start with one of:
ln_live_— production keysln_test_— sandbox keys (no real billing impact)
Scopes
Each key carries one or more scopes. The minimum-privilege principle applies — give a key only what its role needs.
read— call any GET endpointwrite— POST/PUT/PATCH/DELETE on resources the workspace ownsadmin— manage workspace settings, members, billing
A request that lacks the required scope returns 403 INSUFFICIENT_SCOPE.
Storage
We store only a SHA-256 hash of your key. The plaintext is shown exactly once at creation. There is no mechanism to retrieve a lost key — rotate or revoke it.
Rotation & revocation
From Settings → Integrations → API Access:
- Rotate — keep the same name + scopes, mints a new secret. The old secret stops working immediately.
- Revoke — irreversible delete. Use this if a key leaks.
You can also revoke programmatically: DELETE /api/v1/api-keys/{id}.
Workspace binding
Every key is bound to exactly one workspace at creation. The bound workspace cannot change. If a request supplies a workspaceId via URL or body that doesn't match the key's binding, we return 403 WORKSPACE_MISMATCH — your key cannot escape its workspace.
Audit log
Every key creation, rotation, and revocation lands in the workspace audit log with the actor user id, timestamp, and IP. The audit log is read-only and append-only.