HTTP Request Component
HTTP Request
This component allows you to make an HTTP request to an external API, facilitating communication with other systems.
Purpose and utility:
Connect Atom with external platforms through HTTP requests.
Send and receive data in real time.
Integrate with CRMs, databases and other services.
Basic Configuration Section
Available methods: GET, POST, PUT, DELETE, PATCH and HEAD.
Available methods: GET, POST, PUT, DELETE, PATCH and HEAD.
URL: Address of the endpoint to which the request is made.
URL: Address of the endpoint to which the request is made.
Test request button: with the method plus the loaded URL, you can test the request to verify if the connection was successful or denied. It can be displayed as follows:
Test request button: with the method plus the loaded URL, you can test the request to verify if the connection was successful or denied. It can be displayed as follows:
Request body:
If this control is enabled, you can send different data, in JSON and XML format.
Also with the editor, for greater ease, you can expand the section to edit your code more easily, in addition, it will indicate if there are errors, and you can copy or add the parameters you need.
Headers:
When enabling this section, you can configure the types of headers that the request requires. This section contains presets ready to use (such as Authorization, Content-Type or Accept), with the most common fields preconfigured. In addition, sensitive values such as passwords or tokens are shown obscured for security and you have validations and a counter so you know how many headers have been configured.
Advanced Configuration Section
Authorization:
By enabling this section, you can configure the type of authorization required by the HTTP request, such as OAuth 2.0 or Basic Auth.
Save Response:
After testing the request, the JSON appears preloaded and the user only has to click on the field they want to save. Atom will complete the route automatically and you only need to choose where to save it (information field or flow variable). In addition, the option to save the entire response still exists.
📌 Example of using the “Save response” field
Let's assume that we are making an HTTP request to check the status of an order. The API returns a response with the following structure:
{ "data": { "estado": "En camino", "fecha_entrega": "2025-06-10" }}
In this case, we want to store that information to use it later in the flow. So, in the Save response field, we configure two custom variables:
ORDER_STATUS
ESTIMATEDDELIVERYDATE
And we link them with the data that comes from the API response:
data.estado→ORDER_STATUS
data.fechaentrega→ESTIMATEDDELIVERY_DATE
In this way, in the following steps of the flow we can use these variables to display personalized messages such as:
“Your order is currently in status: and we estimate it will arrive on .”
Response code handling:
Now you can define specific branches:
Success (example: codes 200 or 201).
Error (codes 400 or 500).
Retry (for errors such as 429 or timeouts), with the possibility of configuring up to 5 automatic attempts before continuing the flow.
This provides much more precise control over what to do in each situation.
API Timeout:
Defines the maximum time in seconds that will be waited to obtain an API response, being the maximum 60 seconds.