API tokens

Under your account, Create an API token makes a token that acts as you. Under Server, API tokens for this server are the installation's own, for an integration such as a billing system. They sit there rather than under an account because they outlive the person who set them up — a billing system should not stop working because somebody left.

An API token carries its account's permissions and no more, and it cannot change how the account signs in. So a leaked token lets somebody do the account's work rather than take it: they cannot change the password, cannot alter two-factor, and cannot lock you out while they are in.

That is a deliberate ceiling, and it is why revoking a token is a complete answer. Delete it and the access ends; nothing has been left behind in the account's sign-in settings.

The token is shown when it is made and stored only as a hash, so if you lose it, make another rather than trying to recover it. Give an integration its own token rather than sharing one, so that revoking it affects one thing. Where a token is fixed to the address it may be used from, use that — a token tied to your billing server is useless to anybody who steals it.

Every use is in the activity record, which is how you answer what a token did rather than only what it could have done.

The panel stays whole on the free plan: everything a person does in a browser works exactly as it does on Pro or Business. What needs a paid licence is reaching the panel from elsewhere, so API tokens are a Pro and Business feature.

It is the first thing besides the website ceiling that a licence decides, and worth knowing before you build an integration against a free installation.

All guides