Appearance
Authentication
Most Amiqus API endpoints require authentication using a Bearer token. Bearer access tokens can be created by one of two authentication methods:
You should think of access tokens as an alternative to a username and password. All access tokens have the following attributes:
- they are linked to the user who granted the token and are subject to the same permissions as that user;
- all activities are attributed to the token's user;
- their scope of access is limited to the individual team active at the time of token creation.
Personal access tokens vs OAuth 2.0
As for which option is the best choice, this depends on your needs. Each has its own benefits and drawbacks. Below are some examples of the pros and cons of each option.
Personal access tokens
| Pros | Cons |
|---|---|
| Quick to get up and running for development. See Creating a Token | Tokens expire automatically after 1 year and cannot be programmatically refreshed |
| Suitable for simpler integrations | Not suitable for accessing data from multiple accounts |
| Token can be generated by the user | |
| Can be revoked by the user |
OAuth 2.0
| Pros | Cons |
|---|---|
| Relatively common user journey, e.g. Logging in to an application using a social media account | Flow can appear complex for integrators new to APIs |
| Great for scalable integrations that require access to multiple accounts | More involved setup due to redirect URI handling and (optional) token refresh |
| Tokens can be programmatically refreshed without user input | |
| Secure authorisation protocol | |
| Can be revoked by the user |
Our integrators have a wide range of use cases for Amiqus API, utilising one or both of these authentication methods. Some integrators like to get things started quickly in their Sandbox enviroment by generating Personal Access Tokens, and then switching to the OAuth 2.0 flow before the production stage. Others find setting up with OAuth 2.0 from the outset in their Sandbox enviroment to be the perfect way to familiarise themselves with the protocol early in their development cycle. More information about each option can be found in the next pages.