In this article
HTTP requests are an excellent option for cases where you need to send or receive data from a specific application and, at the moment you try to add a connection with this app or a desired action within your automation, you realize that what you are looking for is not available natively in Albato.
Below, we will explain in detail what HTTP requests are and how to configure this important feature step by step in Albato.
What is an HTTP request?
In a simplified way, it is basically a request sent directly from Albato to an external application, asking a specific action to be performed on the other side.
After this action is executed, we receive a response, which may contain a success confirmation, an error message, or even the return of additional requested data.
Using more practical examples, this feature can be used to request specific information, send data, update records, among other use cases.
Imagine you have a new lead who filled out a form in an app, and you want to create a contact in a CRM that doesn’t have a native integration with Albato.
If you have access to the CRM’s API documentation, you can use the technical details provided there to configure an HTTP request in Albato. This allows you to send the lead’s data directly to the CRM and automate the contact creation process.
This is just one example. The possibilities are virtually endless and depend on what the external application’s API allows you to do. Next, we’ll take a closer look at the technical aspects of configuring these requests.
Main types of HTTP requests (Methods)
Each HTTP request uses a method that tells the external application what action you want to perform. The most commonly used methods are the following.
GET
Used to retrieve information.
- Retrieve user data from a specific CRM.
- List completed orders or query products in your e-commerce.
POST
Used to create new data directly from Albato in the external app. Example:
- Create a lead in the CRM.
- Send a completed purchase form.
- Register a sale in a spreadsheet.
Basically, it is used to send data collected in Albato to the desired external app, triggering a specific action there.
PUT / PATCH
Used to update existing data. Example:
- Update a customer’s email address.
- Change the status of an order.
DELETE
Used to delete data. Example:
- Delete a duplicate record.
- Remove a user who has stopped paying for your platform plan.
The method you choose depends on the action you want to perform. By reviewing the external application’s API documentation, you can determine which method should be used in each specific case.
What is a URL (endpoint) within an HTTP request?
Every HTTP request will be sent to an external application. Depending on the action, this request will need to be directed to a specific area of this application or must contain predefined data to ensure its success.
This routing is done through the URL (endpoint), which we will provide when configuring the step in Albato.
What is the structure of an HTTP request?
As mentioned earlier, every HTTP request must include a Method and a URL.

Let’s now examine the additional elements that can be included in a request. When configuring this step in Albato, you will see three main sections where data can be sent or received.
The first section is Headers (Request headers).

This part of the request is processed first by the external application. In most cases, headers contain essential information such as tokens, API keys, and other authorization data required to authenticate the request.
In the HTTP request settings, pay attention to the Header case format field. Some APIs are sensitive to the letter case used in header names. This setting allows you to define how header keys will be sent in the request.

Available options include:
- Title Case (e.g., X-Api-Key);
- lowercase (e.g., x-api-key);
- UPPERCASE (e.g., X-API-KEY).
Preserve original (sends headers exactly as you entered them). You should choose the format that matches the requirements specified in the externalapplication’s API documentation. If the API expects a specific header format and the case does not match, the request may fail due to authorization or validation errors.
The second section is Request Parameters, also known as the Body (request body). This section is typically used with POST, PUT, or PATCH methods.

Here you define the parameters that will be sent to the external application. For example, when creating a new contact, this is where you include fields such as name, email, or phone number.
Finally, there is the Response Parameters section. This is where you configure what information should be returned in response to your request.

For example, you can configure the response to return the request status — whether it was successful, whether an error occurred, or any additional data provided by the external application.
In the case of a GET request, you might send a CRM user ID in the request parameters and configure the response to return additional details about that user, such as name, email, or address.
Where can I find the information needed to create an HTTP request?
To configure an HTTP request correctly, you need specific technical details such as the endpoint URL, required headers, request parameters, and the appropriate method. All of this information is provided in the external application’s API documentation.
Any application that offers an API (meaning it allows remote interaction with other systems) provides documentation that explains what actions are available, what data can be sent or retrieved, and how requests must be structured.
API documentation varies from one application to another. However, it is usually organized into sections based on the type of action (for example, creating, updating, or retrieving data), the available endpoints, required parameters, authentication methods, and other configuration details.
To illustrate this, we will use the API documentation of a CRM called Perfex as an example. Let’s assume the goal is to create a new record (subscription) in this CRM.

In the API documentation, when you locate this action, you will see the method that must be used.

Next, you will see the URL.

And finally, the fields that must be sent.

Note that, in this case, only the field called authtoken, of type String, must be sent in the Header section.
In addition, you will see which fields you can configure so that this new record is created in the CRM, that is, the parameters that you will fill in the Request Parameters (Body) section of your step in Albato.
Finally, you can also configure responses according to the status of your request.
Here, you will have access to all the important information we mentioned and that you need to have in hand before creating your HTTP request.
Attention: each external app has its own documentation. Most of them can be found publicly by searching online; others require you to contact the external app’s support team directly.
Note that Albato does not control which types of actions are available in each app. This is an external configuration and depends entirely on the application to which the request is being sent.
Any specific questions about the documentation or available actions should also be addressed directly with the external app’s team.
Configuring the HTTP request in Albato
Now let’s see how to configure this request directly in Albato.
Creating an HTTP Request
The setup process is similar to creating a new connection. First, go to the Apps tab and click Add a connection.


Here, you will already need to indicate some of the information mentioned earlier.
To start, we will only fill in the URL and the format (Content-type), as mentioned in the example documentation.

The remaining fields (parameters) will be filled in within the automation.
You can add multiple HTTP requests, each one for a specific app or desired action. That is why it is important to configure an internal name in Albato that makes future identification easier.

Once this step is configured, go to the Automations tab and open the automation where you will insert your HTTP Request.
In the place where you would normally add an action step that is not available in Albato, click to add a new step and select the HTTP Request connection you created.

You will see that you have the option to Send Request or Get a File by URL.

We will cover the second option in more detail at the end of this article. For now, select Send API Request. You will see the fields and sections that need to be completed.
Fill them in according to the specifications provided in the API documentation.
In this example, we are using the Perfex API documentation for reference. However, the same logic applies to any application that provides API documentation.
Enter your URL again in the corresponding field.

If it is a dynamic URL, you can add part of it as a fixed value and fill in dynamic values coming from previous steps, for example.

Also fill in the method field.

The protocol field does not need to be filled in unless the API documentation explicitly mentions this requirement.
Next, let’s fill in the Header fields.
According to the API documentation, this is the only mandatory field.

So it will look like this.

Note that, in addition to specifying the exact field name, we also define its type (in this case, String).
Next, let’s configure the fields that will be sent to this app. We will select some of them.

If a field is not marked as mandatory in the API documentation, you may choose whether or not to send it. This depends on which information you collected earlier in your automation and want to send to the external app.
As an example, we will fill in these fields.

Then, in the field on the right, place the values you want to send for these parameters.

Finally, let’s fill in the Response field.

Here, we will configure it to receive a success message or an error warning.

In this way, you will have your API request created correctly, in a simple way, becoming a useful tool for countless situations.
Just activate the automation and you will be able to check the result of this step, just like any other action in your automation, directly in the platform’s history tab.
API requests to access files (Get file by URL)
As mentioned earlier, you can also use an API request to retrieve a file. For example, in one of your automation steps or triggers, you might receive only the URL of a file — not the file itself.
In this case, you can use this step to send a request to that URL. Albato will retrieve the file, making it available for use in subsequent steps that support file inputs.
To configure this type of automation, first identify the correct request URL (endpoint) where the file can be accessed.
The setup process is the same as described earlier: create a new connection, specify the URL and required format, and then select this connection within your automation.

Next, use in the URL field the value collected earlier that contains the file URL, as well as the method set to GET.

The response of this HTTP request will be the file itself, which can be used in several actions that expect this format, such as the Add file action in Google Drive.

Custom API Request x HTTP Request
At some point, when adding an action from a desired application to your automation, you may not find the exact action you want.
However, you may come across an action called Custom API Request.

In short, this action is a simplified version of an HTTP Request. It speeds up the setup process because you do not need to manually include mandatory header data, such as API keys or tokens. Since the app connection is already created natively in Albato, authentication is handled automatically.
If this feature is available for the app you want to use, open the app’s API documentation, find the desired endpoint, and fill in the required request or response parameters as described earlier.
To use the Custom API Request, the app must already have a configured connection in Albato. This connection must be set up correctly, and the Custom API Request action must be available in the app’s action list. If the app is not listed in Albato or the Custom API Request option is not available, you will need to use the standard HTTP Request instead.
Conclusion
This article has explained in detail how to create and configure HTTP Request actions in Albato.
If your goal is to receive data from an external application directly in a trigger step, you may want to consider using the Incoming Webhook feature instead.
You can find a complete guide to this feature here.












