Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt — this page is also available in markdown by appending .md to the URL.
The API Keys API lets an organization administrator manage the ak_* keys used to authenticate the Coverbase public API — without contacting Coverbase support.
These endpoints accept either an admin dashboard session JWT (a user with the admin org role) or an ak_* key that carries the keys:manage scope. The scoped-key path lets headless and middleware integrations manage keys without a short-lived dashboard token. A standard integration key carries no scopes and cannot manage keys, so a compromised integration key cannot be used to mint, rotate, or revoke other keys.
All operations are org-scoped to the caller’s organization and recorded in the activity log as target_type=api_key. The Coverbase backend brokers calls to the underlying identity provider (Clerk), so customers do not need direct Clerk dashboard access. Coverbase stores only the (org, clerk_key_id) → scopes mapping — never the secret.

Key scopes

A key can carry zero or more admin scopes. A standard integration key has none and can only call ordinary /v1/* routes; granting a scope turns a key into a long-lived admin credential.
Granting scopes is a deliberate admin action and requires an admin dashboard JWT. A scoped ak_* key cannot grant scopes — not to itself and not to any other key — so a leaked key can never escalate its own access. A non-admin or scoped-key caller that supplies scopes is rejected with 403 scope_grant_forbidden, and a call made with a key that lacks the required scope returns 403 insufficient_scope.

List API keys

GET
GET /v1/api-keys
Returns every ak_* API key belonging to your org, including revoked and expired keys. Use this to audit which keys exist before rotating or revoking. Auth: admin dashboard JWT or an ak_* key with the keys:manage scope.

Example request

cURL

Example response

Response fields

Each entry contains:
string
The key’s Clerk-side identifier (the prefix portion of ak_*). The raw secret is not returned by this endpoint; it is only available at the moment of creation or rotation.
string | null
Human-readable name set at creation time.
integer | null
Unix timestamp (seconds) when the key was created.
integer | null
Unix timestamp (seconds) of the most recent successful authentication, or null if never used.
boolean
true if the key has been revoked.
boolean
true if the key has passed its expiration.
string[]
The admin scopes granted to the key. Each value is one of "keys:manage" or "audit:read". A standard integration key returns an empty array ([]).
string | null
The Clerk user ID of the admin who created the key.

Create an API key

POST
POST /v1/api-keys
Creates a new API key scoped to your org. The raw ak_* secret is returned once in the response body — store it immediately. Coverbase does not retain the plaintext, so a lost secret can only be replaced (rotated), not recovered. Auth: admin dashboard JWT or an ak_* key with the keys:manage scope. Note that supplying scopes requires an admin JWT (see below).

Request body

string
required
Human-readable name for the key (e.g. "ServiceNow exporter"). Must be non-empty after trimming.
integer
Optional. Seconds until the key automatically expires. Omit for a non-expiring key. Recommended for keys used by short-lived integrations (e.g. 31536000 for a one-year rotation policy).
string[]
Optional. Admin scopes to grant the new key — any subset of "keys:manage" and "audit:read". Omit or pass [] to mint a standard integration key with no elevated access. Granting scopes requires an admin dashboard JWT; a non-admin or scoped-key caller that supplies a non-empty scopes array is rejected with 403 scope_grant_forbidden.

Example request

cURL

Example response

201 Created:
secret is the only place you will ever see the full token. If you lose it, rotate the key (which mints a new secret and revokes the old one). Treat the secret like a password.

Rotate an API key

POST
POST /v1/api-keys/{api_key_id}/rotate
Atomically rotates a key: mints a new key with the same name, then revokes the original. Use this when a secret may have been compromised, or as part of a scheduled rotation policy. The new key inherits the same scopes as the rotated key, so a scoped admin key stays scoped after rotation. If revocation of the original key fails after the new key is minted, the new key is automatically rolled back (also revoked) so the operation never leaves you with two simultaneously-active keys. Auth: admin dashboard JWT or an ak_* key with the keys:manage scope.

Path parameters

string
required
The key’s Clerk-side identifier (the prefix portion of ak_*, as returned by List API keys).

Example request

cURL

Example response

Distribute the new secret to all systems that use the rotated key before removing the old one’s grace period. The old key is revoked immediately on a successful rotate, so any process still using it will start receiving 401 Unauthorized responses.

Revoke an API key

POST
POST /v1/api-keys/{api_key_id}/revoke
Revokes a key. Future requests using the revoked secret are rejected with 401 Unauthorized. The key still appears in List API keys with revoked: true for audit purposes. Revoking clears any scopes the key carried, so a revoked admin key retains no elevated access. The endpoint is idempotent: the first revocation (the active → revoked transition) is recorded in the activity log, but re-revoking an already-revoked key is a no-op that writes no additional audit entry. Auth: admin dashboard JWT or an ak_* key with the keys:manage scope.

Path parameters

string
required
The key’s Clerk-side identifier.

Request body

string
Optional. Free-form revocation reason (e.g. "Employee offboarded", "Suspected leak in Sentry log"). Recorded for compliance.

Example request

cURL

Example response

200 OK — returns the same shape as List API keys, with revoked: true.

Authorization & audit

  • Each endpoint accepts either an admin dashboard JWT (org admin role) or an ak_* key carrying the keys:manage scope. A JWT caller without the admin role, or a key without keys:manage, is rejected.
  • Granting scopes is admin-only. A non-empty scopes array on create can only be supplied with an admin JWT; a scoped-key caller that passes scopes is rejected with 403 scope_grant_forbidden. A scoped key can manage keys but can never grant scopes — there is no self-propagation.
  • Create and rotate always write a CbActivity row (record_creation for create, field_update for rotate) against target_type=api_key. A revoke writes a field_update row only when it actually transitions a key from active to revoked — re-revoking an already-revoked key is an idempotent no-op and writes nothing. These rows are visible to admins in Settings → Audit log (System Audit → Integrations group).

Error responses