Authorization Workflow Settings

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.

Step 1. Authorization settings

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

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.

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

• Type: field type is selected (string, integer, email, password, subdomain, boolean)

• Editable field:

• Required field:

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:

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:

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.

---

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.

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

An update request is made when any app entities make an outgoing HTTP request and the app (service) returns an error that the token has expired.

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.

You can use both fields and authorization parameters. The list of fields depends on the selected method and type.

Available fields:

• Get parameters: entered manually and substituted as GET parameters

• Headers: fields are created indicating the key and substituting the value

• Parameters: fields created for request body

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