Credentials
API keys, the OAuth clients built on them, and JWT signing secrets. Everything that can reach your tenant from outside.
Three kinds of credential, on one screen, because "what can reach us from outside" is one question.
API key
A long-lived secret sent as an x-api-key header. The identity everything else is built on.
OAuth client
A client id and secret exchanged for a short-lived token. Authenticates as the API key it was created against.
JWT signing secret
A shared secret your backend signs tokens with, so your users reach the platform as themselves.
Which one you want
| You have | Use |
|---|---|
| A server calling the platform | An API key, or an OAuth client if you would rather not hold a long-lived secret |
| A frontend whose users each need their own identity | A JWT signing secret, signed by your backend |
| Several integrators who need different configuration | A signing secret each, so environment overrides can differ per integrator |
How they relate
An OAuth client is a second credential for one API key. It reaches exactly what that key reaches, and there are no separate permissions to grant. That is the whole idea: the caller holds a rotatable secret and a short-lived token instead of a key that never expires.
The rules worth knowing before you rely on them
Disabling a key does not disable its OAuth clients. They are independent switches. Not putting a long-lived key on the wire is most of the reason to use a client, so "key off, clients on" is a posture you can deliberately sit in.
Expiring a key does stop its clients. Disabling is a statement about one credential; expiry is the end of the identity, so it takes every credential for that identity with it.
Deleting a key deletes its clients, and their tokens, through the database cascade.
An expiry cannot be changed once set. A key that needs a different date has to be replaced, which is what keeps an expiry a commitment rather than a suggestion.
A secret is shown once, at creation, and is not stored in a form anyone can read back. That is true of API keys and OAuth client secrets alike. If it is lost, rotate rather than go looking: the platform genuinely cannot tell you what it was.
What a credential may reach
Holding a credential is not the same as being allowed to call something. An API key needs a grant per API endpoint, optionally narrowed to particular operations or to read-only. Grants are managed on each API's own page; see API Endpoints.
The credentials screen shows, per key, which APIs it reaches, so "what can this key do" has an answer in one place.