Authentication

Token types

• Workspace API tokens, Bearer tokens issued from Settings → API. Bound to a single workspace audience.
• OAuth 2.0 access tokens, issued to registered third-party clients via the standard authorization-code flow with PKCE.
• Extension tokens, short-lived tokens scoped to the workspace and used by the browser capture flow. Capture-only, no read or generation access.

Scopes

• memory.read, read decisions, sources, prompts, next steps, open questions, constraints, memory health, connector activity
• memory.context, generate context packs and handoffs
• memory.candidates, write review candidates (never trusted memory directly)
• continuations.log, log continuation events for downstream analytics

Scopes are additive. A token with memory.read only cannot write candidates. A token with memory.candidates only cannot read structured memory.

OAuth 2.0 with PKCE

Third-party clients use the authorization-code grant with PKCE required (S256 challenge method). Single-use authorization codes; single-use refresh rotation; immediate revocation. Discovery metadata lives at the standard well-known paths.

GET /.well-known/oauth-authorization-server
GET /.well-known/oauth-protected-resource

The trust contract

No token bypasses review. A workspace API token with memory.candidates can propose new memory rows, it cannot insert trusted memory rows. The same contract applies to OAuth access tokens, extension tokens, connector activity, and capture.

Best practices

• Issue narrow tokens, read-only for analytics, write-only for capture flows.
• Rotate tokens regularly. Revocation is immediate.
• Pass an Idempotency-Key on write calls so retries do not create duplicate candidates.
• Treat the Bearer token like a credential. Store it server-side; never ship it to a public client.