App Integrator Introduction
IN THIS ARTICLE
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 a 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. If a field has been added/removed or the structure of the request has changed, users do not need to create a new automation — changes apply automatically.
- The action has been deleted in the version — Existing automations that use this action will continue to work with the old settings. However, this “old” action will no longer appear when creating new automations.
This scenario is used when changes are significant (for example, API version changes with fully new fields or authorization logic).
You can delete the old action and create a new one with the same name but updated settings. As a result, users in old automations will retain the old action, but new automations will use the updated action.
Did this answer your question?