Skip to main content
The Twine Public API uses Bearer token authentication. Send the token in the Authorization header with the value Bearer <token>:

​
Provisioning a token

Access tokens are short-lived and are generated from a long-lived refresh token. Generate the refresh token in Twine backoffice first, then exchange it for access tokens as needed.
Keep the refresh token secret and never share it. It can be used to mint access tokens for the API.
To obtain an access token:
1

Begin the exchange

Invoke /provisioning/refresh-token/begin using the JTI you received when provisioning the refresh token.
2

Read the salt

The response contains a salt value.
3

Build the signature input

Concatenate the salt with the refresh token, separated by a colon (:).
4

Hash it

Hash the concatenated string using SHA256, for example sha256 "<salt>:<refresh_token>". The hash must be in lower case.
5

Refresh

Invoke /provisioning/refresh-token/refresh with the JTI (as jti) and the hash (as signature) in the body.
6

Receive the access token

The response contains an access token.

​
Legacy tokens

Legacy tokens are still supported. These tokens are long-lived and can be used to authenticate against the API. The token provisioning system above is recommended for new integrations.

​
Token expiration

Provisioned tokens are short-lived. Decode a token to find its expiry time. Legacy tokens have longer expiry times.

​
Permissions

All API requests are subject to a permissions check. Permissions are configured by Twine staff or an approved external admin.