Authentication

Every Cadence API request is authenticated with an API key, created inside your organisation and sent as a bearer token. The key carries both the organisation it belongs to and the member it acts as, so there is nothing else to configure.

Create a key in the product

API keys are created and revoked in the API keys area of your organisation, by an owner or admin. You cannot mint a key over the API itself: this keeps key issuance on the same role boundary as the rest of your admin settings.

1. 1
   Open the API keys area

   As an owner or admin, open API keys from your organisation settings on the website.
2. 2
   Name it, choose a member, choose scopes

   Give the key a recognisable name, pick the member it acts as, and select the scopes it should carry. The key can never do more than that member is allowed to do.
3. 3
   Copy the secret once

   The full key is shown exactly once at creation. Copy it straight into your secret store: Cadence keeps only a hash, so it cannot be shown again. If you lose it, revoke the key and create a new one.

How a key looks

A key is a single opaque token of the form ck_<env>_<prefix>_<secret>. The env segment is live in production and test elsewhere; the short prefix is a non-secret lookup id (it is what you see listed in the product), and the long final segment is the secret you must protect.

Send it as a bearer token

Put the full key in the Authorization header using the Bearer scheme on every request:

GET /api/v1/clients HTTP/1.1
Host: cadencetime.co
Authorization: Bearer ck_live_a1b2c3d4_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

A missing, malformed, unknown, revoked, or expired key is rejected with 401 unauthorized. If the key's member has since lost their place in the organisation, or the organisation is suspended, the request is rejected with 403 forbidden_membership instead, and that key is retired automatically.

Scopes

Each key carries a set of scopes that narrow what it can do. A key with no scopes can do nothing. The available scopes are:

Scopes only ever narrow access: they never widen it past what the key's member is allowed to do. A catalogue:write key whose member is an ordinary member, not an admin, is still refused by the create endpoints with 403 forbidden_role, because creating catalogue records is an admin action. See roles and permissions.

Keep keys secret

• Treat the full key like a password. Store it in a secret manager or environment variable, never in source control or a shared document.
• Use it server-side only. A key in browser or mobile code is exposed to anyone using your app.
• Scope tightly: give each integration its own key with only the scopes it needs, so a leak has the smallest possible blast radius.
• Revoke any key you suspect is exposed. Revocation takes effect immediately and the row is retained for your audit trail rather than hard-deleted.