Skip to main content

Create an API key

Under Settings → API keys.

A key is not personal​

The screen sits with your own settings, which makes it natural to read a key as yours. It is not. A key authorises access on behalf of the organisation.

That changes what a leak means. A key shared too widely, committed to a repository or left in a script does not expose your account — it exposes the organisation's data.

Treat one as an organisation credential that happens to be created from your settings.

Steps​

  1. Go to Settings → API keys.
  2. Create a key and name it.
  3. Copy the key now.
  4. Store it somewhere appropriate.

You will not see it again​

The plaintext is shown once, at creation. Yessort stores a hash of it and genuinely cannot show it to you later — not through support, not from the database.

Lose it and the only option is to create a new one and revoke the old.

Name it for where it is used​

The name is all you will have when deciding whether a key is still needed. "Stock feed — warehouse tablet" tells you what breaks if you revoke it; "Key 2" does not.

Prefer one key per use. Several consumers behind a single key means revoking it breaks all of them at once, and the last-used date tells you nothing about which is still live.

Revoking​

Revoking withdraws the key. The record is kept rather than deleted, so the history — when it was last used, who withdrew it — survives.

Revoke when a key is no longer needed, when someone who had access leaves, or whenever you are unsure where a key has been.

When someone leaves​

Removing a member does not necessarily stop keys they created working, because the key acts for the organisation rather than for them.

Revoke their keys deliberately as part of offboarding — see remove someone.

Checking what is in use​

The last-used date shows which keys are live. One that has not been used in months is usually safe to revoke, and revoking is reversible in the sense that you can always issue a new one.