Introduction
The integration builder allows you to add an app (service) by yourself to Albato, provided that the app has a public API.
The builder consists of many entities that are related to each other and can be used in different places, such as "Authorization", "Trigger" and "Action". Almost every entity consists of a set of its own fields and a set of custom API requests that it will start to receive a response from the application.
The process is as simple as a "copy-paste". You just need to open the API documentation of the app, copy URL request, variables and paste it into the builder.
Workflow
Create an app, name it, then, if necessary, create an authorization to configure a method for obtaining and updating authorization data, if required "Access token" and a "template" for filling an API request with authorization data. Further, you can use the created authorization in other entities, therefore, it will not be necessary to add variables each time in requests, in which the authorization data is placed.
Additionally, you can create the entities that are required to work with the integration. For example, “lists”, which can be static and dynamic, “lists of custom fields” and “webhook catcher”, all these entities are related to triggers or actions.
Create a trigger or an action, depending on what is required of the integration, the necessary fields are created, additional entities are attached, and the behavior of the request API is configured.
Publication
After triggers or actions are added, they will be available only in the Albato personal account that created this application. Any changes that will occur to the application settings will be applied immediately. But if you need your application to become available to all Albato users, you will need to submit the application for moderation. At the time of moderation, as well as after publication, the application is prohibited for editing.
Then an Albato moderator will check the workability of your integration and if all tests pass successfully, your application will become public and available to all Albato users.
And in this way, you can have a huge list of developer-free integrations to your application. Integrations with a variety of CRM, CMS, Marketing systems will be open to your system. All you need to do is add your application.
Versioning
When the application is published and you need to change something, then a new version is created (copy of the public version).
In this version, you can add/modify/ delete all entities. After making all the necessary changes, send the application for moderation. After creating new version with changes, it will be available in the personal account of the user that created the application. Other Albato accounts will have the previous public version. After moderation, versions are “merged”, and your new version becomes available to all users. Let's consider the behavior during the “merge” using the example of the “Action” entity:
An entity has been added to the version - Users have new entities, while creating automations, they can select a new action.
The existing action has been changed in the version - For users, in all current automations the step is replaced. That means if a field has been added / removed or the structure of the request has changed, then users do not need to create a new automation, all changes will occur in the existing automations. This scenario is suitable when you have minor changes that little affect the operation of the action. Example: changing the name of the field, adding a field, changing the structure of a query with the same fields.
The action has been deleted in the version - For users who already have an automation with this “old” action, the automation will continue to work, the step will be unchanged, and the requests will go according to the old settings. However trying to create a new automation, the user will no longer have this “old” action, it can only work in previously created scenarios.
The latter scenario is possible when the changes are significant (for example, API version changes, due to which the authorization or the set of fields have been changed completely).
You can delete the "old" action and create a new one, the same one with the same name, but with new settings. As a result, users in the old automations will have the old version of the action, but when they create a new automation and select this action, they will already have a new step that works with the new scenario.