User API tokens can be used in the authentication header instead of a User Session.
The key benefit is that API tokens do not expire (and thus they don't need to be refreshed).
While these tokens do not expire, they can be disabled and / or deleted. We log the use of your API token and provide the timestamp of its last use. A disabled token can be re-enabled. Before deleting a token, we recommend that you first disable it and monitor for any rogue process you might not remember. This will allow you to quickly re-enable a token should something break.
User API tokens are functionally the same as user session tokens. You will be allowed to perform all actions for a given application that your user is scoped to perform. Guard API tokens as carefully as you would your password; they are just as powerful...
Be careful
Because user API tokens inherit all scopes of the underlying user, they should not be shared. User API tokens are functionally the same as a username and password; they should be guarded just as carefully.
User API tokens should not be used in deployment systems. For backend systems, we recommend using Application API Tokens.
Security protection
User API tokens cannot be used to transfer ownership of an application or to manage the user's API tokens. Only a user session token can be used in these API calls.
Attributes:
| Name | Type | Description |
|---|---|---|
| id | string | V7 UUID generated when the API token is created. |
| name | string | A human-readable name for the API token. |
| user_id | string | The id of the underlying user record. |
| enabled | boolean | If this API token is enabled. Disabled tokens will fail authentication, but can be re-enabled. |
| last_used_at | integer | Unix timestamp of when the token was last used in an API call (in seconds since the Unix epoch). |