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.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.
List API keys
GET
GET /v1/api-keysak_* 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-keysak_* 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:
Rotate an API key
POST
POST /v1/api-keys/{api_key_id}/rotateak_* 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}/revoke401 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
adminrole) or anak_*key carrying thekeys:managescope. A JWT caller without the admin role, or a key withoutkeys:manage, is rejected. - Granting scopes is admin-only. A non-empty
scopesarray on create can only be supplied with an admin JWT; a scoped-key caller that passesscopesis rejected with403 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
CbActivityrow (record_creationfor create,field_updatefor rotate) againsttarget_type=api_key. A revoke writes afield_updaterow 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).