Authentication with an API key can be done by using a bearer token in the Authorization header. This is done using the following format Authorization: Bearer {token}. The API token can both be issued and revoked directly from the platform. Please go to the menu on the right side, click Developers and then API. Name the API token and associate your needed scopes.
Scopes
Every endpoint requires a scope, and a token only reaches the endpoints its scopes cover. A scope is an access level and an area joined by a colon:
The access level follows the HTTP method — GET requires read, and every other method requires write. The area is named on each endpoint under Required scope.
Grant a token the narrowest set that covers what it does. A token that only mirrors data into a warehouse needs read scopes alone.
Sub-areas
Some areas have a sub-area, written with a dot:
A scope grants exactly what it names. write:interactions does not grant write:interactions.create, and write:interactions.create does not grant write:interactions. If a token needs both, give it both.
Because a scope does not cascade, a token that gets a 401 on one endpoint
may work fine on a neighbouring one in the same area. Check the Required
scope on the endpoint itself rather than assuming the area is covered.
Checking a token’s scopes
GET /iam/auth/permissions returns the scopes the calling token carries. It requires no scope itself, so it is the quickest way to confirm a token was issued with what you expect.
When a scope is missing
A request made with a token that lacks the required scope is rejected with 401 Unauthorized:
The scopes on an existing token can be changed under Developers → API in the platform without reissuing it. 
