HTTP Request Step

A guide to setting up HTTP requests as a step in your call flow designer.

T
Written by Tom Grant
Updated over a week ago

The HTTP Request action within the call flow designer replaces External API and Webhook actions. Reference this article for a proper request setup.

User Level:

  • Admin


Using an HTTP Request Step

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}}

      • {{contact.emails[index]}}

        • Returns an individual email from the indexed position

    • 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.subkey combination

    • For example, the body entries would be defined as

      • customer.firstname = John

      • customer.lastname = Doe

    • The resulting object will look like:

      { “customer”: { “firstname” : “John”, “lastname” : “Doe” }}

Parse response

  • In case this is enabled, the call flow it is part of is required to wait for a HTTP response before moving to the next step.

  • In case this option is disabled, the call flow will continue after sending the request, regardless of whether a response was received or not.

  • This option is useful in case of further steps working with data present in HTTP response, such as the Condition Splitter step.


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!

Did this answer your question?