Application is a service that has been added to the builder and contains all the collected entities. It is a key chain of "Connection" + "Triggers" or "Actions". It is displayed on Albato list of connections as a partner available to the user.

Request widget is a widget that configures an HTTP request to the API. You configure an outgoing request, response parser and error handling for this request. It appears in all entities that make API requests.

Connection. The user grants access to the application with his data. All entered data when granting access are saved within one connection and used in the future to build API requests. The number of connections is not limited.

Authorization is the generated authorization behavior model in the application. This section is to configure the parameters to ask the user when creating a connection, to save this data in the connection memory and then transfer it in all other API requests. If necessary, you can also configure the model for obtaining access token and its updates.

Connection Fields: Custom fields that are requested from the Albato end-user when creating an application connection. These are fields that are not directly related to authorization and can be used everywhere. For example, it can be a domain or subdomain that the user will specify in the connection and the value will be saved within the framework of his connection. Further, the value can be used in all other entities by substituting it in the request URL.

Triggers. It is an entity that responds to the event, depending on the settings. When the event occurs, the automation is started and receives data from this event and passes it on to the action steps. Triggers have two behavior models: “Webhook” - the trigger is started when a request arrives at a specific URL and passes through the filter; “API” - the trigger independently query the service via HTTP requests every five minutes, receiving a list of new/changed entities, filtering additionally entities by ID/Modification Date (that you don't get duplicates).

Actions. It is an entity that makes an outgoing HTTP request to the service, according to a given scenario (to a specific URL with a pre-configured request body). The action takes place after the trigger has occurred in the bundle and sends all the filled fields of the bundle to the service.

Lists can be Dynamic (getting elements through the API) or Static that can be assigned to a specific action field. For example, there is a “Status” field that you need to fill with the ID of the certain status, but the statuses and these ID are different for everyone. The dynamic list will allow you to get the statuses IDs from the end-user and make a list in the action settings. The list can also be static, with a specific set of elements.

Webhook catcher. It is an entity that links to triggers with the “Webhook” behavior. The catcher allows you to get a test webhook in an automation with all the necessary parameters, and for each parameter create a separate trigger field, the values of these parameters will be transferred to these fields. It is necessary when the trigger shows no set of static fields and each time you need to get different ones.

Custom field lists are like usual lists. Through the API, it receives a list of specific custom fields, the list is linked to a trigger or action, and the user gets his fields.

Line section/String: A specific set of fields, which is in an array of objects ([{}]), it can be received in triggers and passed in actions. A section is one specific array, and the fields of the section are the fields that are in each object of this array. By adding a string to the trigger, you can get the event with the entity, and its entire attached array (e.g., Goods), which doesn’t have strictly defined set of objects.