Skip to main content
All CollectionsApp IntegratorAuthorization
Authorization Workflow settings
Authorization Workflow settings
Manuel Bernal avatar
Written by Manuel Bernal
Updated this week

General information

Authorization settings include four steps. Some steps are unavailable using a special combination of Type and Method. Each step allows you to save Authorization and return to settings later. When Authorization is completed, each step also can be edited.

image.png

Step 1. Authorization settings

Enter an Authorization name, type and method at this step. Using the oAuth method, set up additional fields.

image.png

Type and Method cannot be edited when Authorization is completed. In case of incorrect type or method, create the Authorization again.

Step 2. Authorization fields

This step appears for Custom type only.

image.png

Fields required for Authorization are created, which will be requested from the end user at the time of creating app connection.

All created fields will be displayed for filling, the values of these fields will be saved within the connection.

The fields themselves can be used as dynamic variables in the next steps, substituting them in HTTP requests.

Creating a field, fill in the following values:

  • Field code: internal ID field

  • Name in English: name will be displayed to the end-user in Albato English interface

  • Hint in English: text will be shown under the required field as an explanation. Displayed in Albato English interface.

  • Type: field type is selected. There are: string – a regular input string; integer – allows to store only numbers; email – allows to validate email before saving; password – entered data will be hidden with dots; subdomain - the end-user will see a static prefix and postfix; boolean - checkbox field.

  • Editable field:

  • Required field:

image.png

All fields can be edited and deleted.

Step 3. HTTP authorization requests

This step becomes available to set up only if Authorization needs to make additional HTTP requests to receive/update an access token. Available for Authorization methods “with login and password” and “with API key”.

Requests widget for receiving and updating tokens are created and set up.

If the token needs to be refreshed exactly through the refreshToken, you need put a check in Use RefreshToken box:

image.png

This checkbox allows in the Response tab of the first request widget (which receives the Access token) to save the Refresh token received in the response to a variable:

image.png

Further, creating a token update request widget, this variable will be available in the Request tab, and the value of the variable (which we have previously saved) will be passed in the token update request.


The first request widget is added. This HTTP request is made at creating a connection. Specify URL, method and format of the request, as well as set up the body and headers.

The key of the variable is indicated in the left field, the value is in the right, where dynamic variables (authorization fields) can be substituted. It is also necessary to set up the Response tab, it indicates the value to take in the Response variable and to save in the accessToken variable. It will be further transmitted for all outgoing HTTP requests from the application.

image.png
image.png

If you need to update a token, add the same request widget in the “Update token” section. In this request, you can again pass the same dynamic variables, as well as previously received Access token and Refresh token.

image.png

It is important to set up the response parser in the Response tab in order to receive, update and save a new access token.

image.png

An update request is made at the moment when any app entities makes an outgoing HTTP request and the app (service) give an error that the token has expired (the widget must have Errors handling with the appropriate type).

Step 4. HTTP request template

This step appears for any type and method of Authorization.

A “template” of the behavior of all future HTTP requests to the API is set up. It will be associated with this Authorization. It means all the necessary parameters set at this step will be substituted. It is a “cut” version of the request widget.

image.png

You can use both fields and authorization parameters. The list of fields depends on the selected method and type. For example, if the Authorization method is oAuth and With API key, the dynamic API Key (accessToken)variable is available. This variable has the value saved using the HTTP request at creating a connection and exchanging data for token access. If the Authorization type is “with login and password”, the dynamic variable Login and password in base64 format will be available, by gluing the login and password through the symbol : in base64 format.

image.png

Available fields:

  • Get parameters: The necessary parameters are entered manually and the values are substituted. Everything indicated in this field will transfer the entered data with each HTTP request, substituting exactly as GET parameters

image.png

  • Headers: fields are created, indicating the key in the left field and substituting the value in the right field

  • Parameters: create fields that will be transferred in the request body

image.png

This is the last step. Saving it, you complete the Authorization. Now you proceed to the settings of the rest entities.

Did this answer your question?