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
• What authentication methods are available
• 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 five 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 authentication method

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

The second section is for your Authentication method; this will serve as your authorisation for the call, for security purposes. It can be used further in your configuration, e.g. as part of any headers you may add. You can choose between several types of methods, including no authentication at all.

Please see more details on all of these methods in this section of the guide.

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, if you're using a custom authentication method, chosen earlier):

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.

The Body field supports three types of queries: JSON, Text, and GraphQL:

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.

Authentication methods

💡

Security first: Whenever you add sensitive data (tokens, passwords, keys), use the secure placeholder mechanism. Never paste secrets directly into the header, URL, or body fields.

 

There are four different authentication methods that you can use for your API call: API key, none, bearer, and basic. Choose the one that is most appropriate for the given request, and make sure to configure it correctly.

 

API key

This method is a flexible solution for any other types of authentication that aren't covered by the other methods. You should store your API key (or authentication key, or access token, or secret) and then use that securely stored value with a placeholder in any request field (like header, URL, or POST body). Your request will be sent with your sensitive data in place of this API key placeholder. This way we can keep your token/key/secret encrypted and secure, so it won't be visible in any part of our system, and safe from any potential security incidents.

Remember: never put your sensitive data directly into the request's header, URL, or body. This can be the source of security issues; please be responsible with your access.

 

 

 

• When to use: Should be used with any API that supports a different standard than those available through the other methods.
• How to configure:
  1. Store your token/key/secret in the API key field.
  2. Insert the {API key} placeholder wherever the key should appear: a header, query string, or body.
  3. An example header would be X-API-key with the value {API key}

 

 

 

If the API key is not placed in the request in any way, you will see an alert regarding that - reminding you of this necessary step:

 

 

 

Basic

This is a standard method of authentication, based on logging into a specific resource. You will need to provide your login credentials (username and password). We keep your credentials encrypted and secure, so they won't be visible in any part of our system, and safe from any potential security incidents.

 

 

 

• When to use: Should be used with any APIs that support this standard.
• How to configure:
  1. Enter your username and password.

  2. The request is sent with the header Authorization and the value Basic <base64(username:password)>

      

Bearer

This is a widely adopted method that transmits an access token in the request header. We keep your token encrypted and secure, so they won't be visible in any part of our system, and safe from any potential security incidents.

 

 

 

• When to use: Should be used with any APIs that support this standard.
• How to configure:
  1. Paste your Bearer token into the designated Bearer token field.
  2. The platform automatically sends the header Authorization with the value Bearer [token]

 

 

None

This method should never be used with your internal tools, nor with any API that expects a token, secret, or key.

 

 

 

• When to use: Only for publicly available APIs that require no authentication at all.

 

 

Best-practice reminders

1. Never hard-code secrets directly in request fields.
2. Rotate tokens and keys regularly.
3. Revoke credentials immediately if you suspect compromise.
4. Grant only the minimal scope or permissions the integration needs.

 

By following these guidelines, you’ll keep your credentials secure while ensuring your requests authenticate correctly.

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 dataConfigure 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 informationIf 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.