The HTTP Request step lets you connect your CloudTalk call flows with external systems and APIs. In this guide, you’ll learn how to configure and use the HTTP Request step to send requests, handle responses, and integrate external data directly into your call flows.
User Level:
Admin
Using an HTTP Request Step
The HTTP Request step is a powerful tool that allows you to extend your CloudTalk call flows beyond the platform itself. By connecting to external systems and APIs, it enables seamless data exchange, automation, and real-time decision-making.
Whether you’re enriching call data, updating external records, or personalizing customer experiences, the HTTP Request step gives you the flexibility to build smarter, more connected workflows.
Configuring HTTP Requests
In order to include HTTP Requests within your call flow, the following elements will be necessary to configure:
Endpoint
The endpoint defines a digital location to be called. This typically looks like a URL or Token URL.
Communication with this digital destination requires HTTPS.
Method
Method refers to the HTTP Request Method or the type of action that the endpoint receiver is being asked to perform.
Available options for methods are GET, POST, PUT, PATCH, DELETE
(Optional) Request Headers
Request headers are used to provide meta-information about requests, including the format of the request body or authorization.
CloudTalk allows you to define any number of additional headers, or none at all if necessary. The type of headers depends on the definition of the external API call flow is trying to communicate with.
For example, the configuration of Request Headers can look like this:
Request Body
The Request Body refers to the payload which will be sent in the request.
You can define any number of [key, value] pairs to serve as data attributes in the request body.
Apart from defining a constant value, you can use the following dynamic value variables:
Call Attributes
{{call.external_number}}
number of the caller written in E164 format
+(country code)(number with area code)Example:
+10005555555
{{call.waiting_time}}
Current waiting time, which includes the time in seconds between when the call was started up until it was picked up by the agent
{{call.uuid}}
Only for an answered branch, otherwise returns
null{{call.agent_id}}
{{call.agent_email}}
Contact Attributes
{{contact.name}}
{{contact.id}}
{{contact.title}}
{{contact.company}}
{{contact.industry}}
{{contact.address}}
{{contact.city}}
{{contact.zip}}
{{contact.state}}
{{contact.type}}
Returns type of contact (“contact“ or “lead“)
{{contact.tags}}
Returns array of assigned Contact Tags
[“Vip”, “CampaignA”]
{{contact.custom_fields[“custom_field_name”]}}
In case a contact custom field is defined in company settings, it is possible to reference its value (e.g.
{{contact.custom_fields[“MRR”]}})
{{contact.emails}}
Returns array of contact’s emails
{{contact.emails[index]}}
Returns an individual email from the indexed position
for example,
{{contact.emails[0]}}returns the first email
Collect Input
{{input[collect*_input_id*].value}}
returns value inserted by caller during a collect input step with id defined in “collect_input_id“ eg. {{input[123].value}}
please be aware of that:
collect input can be empty (caller didn’t insert value correctly)
it is possible to use the temporary ID of the CFD step during initial creation of the sequence (it will be replaced after the call flow is saved).
The request body is sent in a JSON format (for example: {“key1”:”value1”, “key2”:”value2” })
Nesting options
In case an external endpoint requires nested objects, it is possible to use dot notation in a form of
key.subkeycombinationFor example, the body entries would be defined as
customer.firstname = Johncustomer.lastname = Doe
The resulting object will look like:
{ “customer”: { “firstname” : “John”, “lastname” : “Doe” }}
Parse Response Setting
The Parse Response setting defines how CloudTalk should handle data received from an external resource and whether the HTTP response needs to be processed before continuing the call flow.
When Disabled
If this option is disabled, the call flow will continue immediately after sending the request, without waiting for a response.
This is useful for asynchronous or fire-and-forget requests where the response data is not needed later in the flow.
When Enabled
When this option is enabled, the call flow will wait for the HTTP response before proceeding to the next step.
This allows the system to process the returned data and make it available for use in subsequent steps within the flow.
Using the Response in Later Steps
When the response is processed, its body can be used in later steps — for example, in a Condition Splitter.
In the Condition Splitter configuration:
Select HTTP Response from the Property dropdown.
Enter the JSON path to the response property using dot notation.
Example: If the response from external endpoint looks like
{
"status": "success",
"error": {
"code": 200,
"message": "OK"
}
}To reference top level property status, use
status
To reference nested property error, use
error.code
For indexed (list or array) properties, use dot notation with the index number.
For example: if the response contains a list under
status, usestatus.0to access the first item in the list,status.1for the second, and so on.
Define the desired condition (Operand and Value) based on the need.
With this setup, every time a call reaches the HTTP Request step, it will send a new data request to the external system. The response data will then determine the call’s next routing path, allowing each interaction to be handled dynamically using the most up-to-date information.
If you have any further questions regarding HTTP requests or any other topic, please reach out to our Support team. We are always happy to help!