Authentication

Diska has two authentication mechanisms, for two different uses:

API keys (API Channel)

API keys are managed in Settings → API Keys and authenticate the API Channel — the public REST surface at https://api.diska.ai/v1. Each key has a name, an optional description, a masked preview, optional scopes (no scopes = full access), an optional expiry, a creation date and last use, and can be revoked at any time.

The key is sent in one of these headers:

Authorization: Bearer dsk_…

X-API-Key: dsk_…

A key acts only on its own organization's data — reads (agents, calls, analytics, numbers, knowledge) plus the writes its scopes allow (agent create/publish, knowledge ingestion, webhook management); it is not accepted by any internal /api/v1 endpoint. See API Keys for management and API Channel for the endpoints.

Backoffice sessions (Better Auth)

Signing in to app.diska.ai is handled by Diska's identity service, built on Better Auth. After login, the backoffice sends a short-lived, asymmetrically signed JWT with every internal API request, verified by the API via JWKS — no shared secret ever leaves the identity service:

Authorization: Bearer <jwt>
X-Organization-Id: <organization_id>

Organization selection

A user may belong to multiple organizations. The active organization is determined by the X-Organization-Id header; the backoffice lists the user's organizations and records the switch:

GET /api/v1/organizations

POST /api/v1/organizations/switch
{
  "organization_id": "<id>"
}

Organization roles

Access within an organization is defined by the member's role:

Permission checks are performed server-side from the role; internal permission identifiers are not part of the public contract.

Authentication errors