Skip to main content
All CollectionsApp IntegratorAuthorization
Introduction to the Authorization Section
Introduction to the Authorization Section
Manuel Bernal avatar
Written by Manuel Bernal
Updated this week

General information

The authorization is an entity where we configure the type of data that will be requested from end users and the way to get an access token to the application through the API.

Applications can have an unlimited number of Authorization. In each request widget, a specific Authorization is selected, and such a request will be made with the same Authorization access token.

The last step of Authorization includes the “template” of an API request with Authorization data. It helps users to avoid these settings in each request widget. For example, if the Access token is always passed in a specific header, then at step 4 you will need to create this header and paste the Access token in the value.

Authorization set up

Each authorization consists of 4 steps. How to set up each step we describe in this section.

Authorization is created "by template". That is, when selecting a template, fields are created in each step and requests are filled out depending on the template. After creation, you can update them, add/delete/rename fields/requests. With the exception of oAuth, this is the only authorization with its own logic.

In each authorization, in step 4, there is an encoded string - Base64

image.png

You can put in it any field and authorization parameter with necessary format. Then in the headers or parameters select the result of the base64 string.

image.png

Authorization templates

Five authorization templates are available:

image.png
  • oAuth 2.0 - The only separate type of authorization. It has its own additional settings on step 1. It creates 2 fields - Access token and Refresh token - as well as requests for receiving and updating token.

  • Basic - Basic authorization. Login and password fields are created. No requests are created. On the 4th step, the rule for base64 string is filled (login:password) and the header contains the result of encoding in the form of Authorization: Basic {{base64string}}.

  • API token - Authorization with static API token. One API key field is created. No requests are created. On step 4 the API key is passed in the headers - Authorization: Bearer {{apiKey}}

  • Session auth - Same as the API token, but there is an additional uneditable access_token field and a request that allows to exchange one set of data (Login and password or static API key taken from interface) for final API access token. This means we make a request with editable fields, in response we get 1 or more parameters required for authorization, save them to the non-editable fields in the response and use them on step 4 in the request sending template.

  • Custom - Empty template. It does not create anything. It is used when the set of fields is too custom and it's easier to create authorization from scratch.

Create an authorization that is best suited to your needs and then edit the authorization steps if needed.

Did this answer your question?