Flows: Making an API call (HTTP request)

It is possible to make HTTP requests in Tidio via flows, with the help of the API call action. This allows you to send data from Tidio to external systems (such as a CRM or an email marketing tool), and to get external data into Tidio during live chat interactions. This makes not only for a great lead generation tool, but is also a flexible way to present necessary external information to your Tidio chat visitors.

For example, when a visitor inquires about their order status, your flow can prompt them to provide their order number. Tidio can then send a web request to your server and obtain the order details (you also decide which information is returned to the visitor).

In this article, you will learn:

• How to add the API call action
• What types of requests are available
• How to configure your requests
• How to handle matters of security

Adding the API call action to your flow

Inside the flow editor, open the Actions menu on the right - and you will find the API call action listed there:

Add it wherever necessary in your current flow; once a visitor interacts with this flow and reaches the API call action, it will carry out any valid instructions that you configure inside this node.

To set up these instructions, use the Configure HTTP request button inside the action, and you will be able to configure all the necessary details.

Inside, you will see a screen with all the available options, including the ability to test your request:

Types of available requests

There are four types of HTTP requests that you can make via the API call action: GET, POST, PATCH, PUT, and DELETE.

• GET requests
• POST requests
• PATCH requests
• PUT requests
• DELETE requests

GET requests

This request allows you to pull data from an endpoint. For example, it can be used to get specific order details, or a list of contacts, etc.

POST requests

This request allows you to trigger some action in the target software, or send data. For example, it can be used to generate a new contact or ticket in an external CRM.

PATCH requests

This request allows you to update something that already exists in the target software. For example, it can be used to add new details to leads in a CRM.

PUT requests

Similarly to PATCH requests, this request allows you to update information in the target software; and similarly to POST requests, it can also be used to create something in the target software. The difference is that PUT requests are idempotent - i.e. executing the same request multiple times will have the same result as executing it just once.

DELETE requests

This request allows you to remove data from the target software. For example, it can be used to delete a ticket or contact in a CRM.

Configuring your requests

When you're configuring your HTTP request, there are several fields available to set up - and they change depending on the type of request you're configuring.

Request name and Access token

The first field is the Request name; it is simply way for you to quickly identify the request within Tidio, and it's not used in any other way.

The second field is your Access token; this will serve as your API key or similar token, and is kept fully secure. It can be used further in your configuration, e.g. as part of any headers you may add.

Headers

Here you can set up your header(s), where you need to provide a Key and Value (this is also where you can use the Insert access token option for quick input):

Method & URL

In this section you define the request type (GET, POST, PATCH, PUT, or DELETE), and provide the necessary details for it to work:

Apart from the URL field, you will also see the Body field to complete (it's not available for GET requests). In both fields, you can also use the Insert Contact Property or Access token option.

Output (test)

Once your request is fully configured and valid, you can use the Test button at the bottom. If successful, you will see resulting API response in the Response field on the right:

When you're done with setting up the request, make sure you hit the Add button at the bottom in order to save your setup.

Security considerations

It is crucial to carefully decide what information you disclose to visitors. An imposter might request order details for an order they have not placed, attempting to access other customers' information. For instance, if you return sensitive information such as email addresses, phone numbers, names, or street addresses, an attacker could enumerate order numbers to retrieve confidential data about your customers. This risk is heightened if you accept order numbers in a predictable format, such as sequential integers (e.g. 8123, 8124, 8125, etc.).

Recommendations

To mitigate these risks, we strongly advise you to:

1. Limit returned information to non-sensitive data
   Configure your API Call action to return only non-sensitive information, such as the order status (e.g. "shipped," "processing," or "awaiting courier").
   
   
2. Require complex data format before returning sensitive information
   If you need to return sensitive information, ensure that you require unpredictable identifiers before doing so. Instead of using predictable, incremental order numbers, consider using unique identifiers in UUIDv4 format (e.g. 29c7be5f-0f9c-4264-a86e-6733beecf0d8, d425fc88-579c-4a91-a940-68c750db08ff, etc.). These IDs are random and cannot be easily guessed by attackers.

The same security considerations apply to other functionalities you may want to automate using the API Call action.