Skip to content

HTTP request ​

The HTTP request action connects your assistant to any system that has a web address: your CRM, your job-scheduling software, your own API, or an automation platform such as Make or n8n. You can send a request before the call (to fetch context), during the conversation (as a tool for the assistant) or after the conversation (to push data out).

You create the action per assistant under Assistants → Tasks, on the Actions card: click Add new and choose HTTP request. This takes the Editor or Admin role. Changes save automatically once the action has a name and a valid web address.

For a general explanation of actions, conditions and variables, see Actions.

Common settings ​

SettingMeaningDefault
NameA recognisable name for the action. Required.—
WhenBefore the call, During the conversation or After the conversation.After the conversation
MethodGET, POST, PUT, PATCH or DELETEPOST
URLThe full address, including https:// or http://. Variables are allowed, e.g. https://api.example.com/customers/{{inboundContext.customerId}} on a request after the conversation. Internal and private addresses are refused.—
HeadersKey/value pairs, e.g. X-Api-Key: …. Variables are allowed. These values stay readable in the form. Without your own Content-Type we send application/json.None
Authorization keyA stored key that we send as the Authorization header. The value goes out exactly as you stored it, so add Bearer yourself if your system expects it. Choose a key from the list, or paste one at Paste a new key and click Store as key. You can also add it beforehand under Settings → Connections with the kind Authorization header. The value is stored encrypted and never shown again. The key is only sent during and after the conversation, not on a request before the call: there, put the value under Headers as Authorization: ….None
Body templateJSON with variables (not for GET, which has no body). Empty means: all variables available at that moment, as JSON.Empty

We do not wait for a response indefinitely, and you cannot change how long: 3 seconds before the call, 6 seconds during the conversation and 8 seconds after the conversation. A failed request is not retried.

Signature ​

Every request with a body carries the X-Yarla-Signature header, so your system can verify that it really came from Yarla. A GET request has no body and is not signed. The header looks like this:

text
X-Yarla-Signature: t=<unix-timestamp>,v1=<hex>

Here v1 = HMAC-SHA256(secret, t + "." + rawBody): an HMAC over the timestamp, a full stop and the raw body, keyed with your business webhook secret. You find that secret under Settings → Connections, on the Webhook secret card. Only an Admin sees that card. The Generate new button creates a new secret; the old secret stops working immediately, so update your system straight away. A verification example is in Webhooks.

Before the call ​

A request before the call is sent as soon as an incoming phone call has been answered, before the greeting. It runs on every incoming phone call; a condition has no effect here. It does not run for outbound calls, SMS, WhatsApp, webchat or Try it out, so test it with a real incoming call.

With an empty body template we send this body, with the full stop literally in the field name:

json
{
  "fromNumber": "+447700900123",
  "toNumber": "+442012345678",
  "personNumber": "+447700900123",
  "agentNumber": "+442012345678",
  "company.name": "Jansen Plumbing",
  "company.website": "https://www.example.com",
  "company.phone": "+442012345678",
  "company.email": "info@example.com",
  "company.address": ""
}

Your system responds with a JSON object, preferably flat. Every field in it becomes available as a variable. Any other kind of response, such as a list or plain text, is ignored. If you have several requests before the call, they run one after the other and their responses are merged.

json
{ "customerName": "Jan de Vries", "openInvoice": true, "plan": "Comfort" }
  • In the greeting of that call you use the fields directly: {{customerName}}, {{plan}}.
  • The assistant receives the fields as context during the call by itself. So you do not need them as variables in the instructions; an unknown variable stays empty there.
  • Afterwards the same fields sit under inboundContext in actions: {{inboundContext.customerName}}. In the Inbox you see them on the conversation under Technical details.

An example greeting that uses the context:

text
Good afternoon {{customerName}}, welcome to {{company.name}}. How can I help you today?

Respond within 3 seconds

The caller is waiting. If no response arrives within 3 seconds, or your system returns an error status, the call proceeds without context and the variables stay empty. Keep the lookup fast, and choose a greeting that still sounds natural without a name.

More detail: Inbound webhook (pre-call).

During the conversation ​

During the conversation, the HTTP request becomes a tool the assistant uses itself whenever the condition is met, on every channel. You enter the condition at When should the assistant use this?. You also specify three extra things:

SettingMeaningDefault
Parameters the assistant fillsThe data the assistant must extract from the conversation: name, type (string, number, boolean), description and whether they are required. For example orderNumber, string, "The order number the caller mentions, six digits". Use them in the URL and the body template as {{orderNumber}}.None
Response hintTell the assistant what the response contains and how to use it, e.g. "The response contains the delivery date. Read it out and ask whether that suits."Empty

On a phone call, the assistant can say in a few words that it is checking while the request runs.

Your system's response (JSON or text) is handed back to the assistant, who works it into the conversation straight away. It receives at most 6,000 characters, so keep the response compact: only the fields the assistant needs. If your system returns an error status, the assistant only hears that this happened.

Rely on your parameters

Do not count on anything but your parameters and the variables of a campaign or an API call. Built-in variables such as {{personNumber}} and {{conversationId}} stay empty here, and anything looked up before the call normally does too. If you need the caller's number, make it a parameter.

Under Call and Chat in Try it out the request is only really sent when Perform actions for real is on. Otherwise the assistant gets a simulated response. Real call places a real call, so the request is always really sent, and actions after the conversation run too.

Example request for an order status:

text
POST https://api.example.com/orders/status
{
  "orderNumber": "{{orderNumber}}"
}

Your system's response:

json
{ "status": "shipped", "deliveryDate": "2026-09-14", "carrier": "Royal Mail" }

At When should the assistant use this? you could enter: "The caller asks about the status of their order and mentions an order number." More detail: Webhook during the call.

Does the answer hold personal details, such as an order or a customer file? Turn on Ask for a code first. When the customer calls from a number that isn't withheld, that number is enough for a GET request, which only looks something up, and no code is needed. Another method (POST, PUT, PATCH or DELETE) can change something, so then the assistant first texts a code to the number they are calling from, unless their carrier confirmed the number. With another number, a withheld number or in a chat, the assistant first texts a code to the customer's number, after they said yes, and only sends the request once the customer gives that code back. Look the record up with {{verifiedPhone}}, the number the customer proved, and not only with a number the assistant passes on: our platform fills that variable, the assistant can't. See Caller protection.

After the conversation ​

After the conversation you push data out. This also runs when an SMS, WhatsApp or webchat conversation has ended. At Under what condition should this run after the conversation? you enter a condition in plain language; empty means after every conversation. Leave the body template empty and we send all built-in variables plus your own variables (Custom variables to extract) as a single JSON object:

json
{
  "personNumber": "+447700900123",
  "agentNumber": "+442012345678",
  "conversationId": "<conversation-id>",
  "conversationLink": "https://<dashboard-domain>/en/inbox/<conversation-id>",
  "startTimestamp": "2026-09-11T14:32:10.000Z",
  "direction": "inbound",
  "channel": "voice",
  "durationSeconds": 184,
  "disconnectReason": "normal_clearing",
  "summary": "Mrs de Vries reports a leaking kitchen tap and would like a call back today.",
  "plainTranscript": "Assistant: Good afternoon, ...\nCustomer: ...",
  "audioLink": "https://<dashboard-domain>/en/inbox/<conversation-id>",
  "outcome": "callback_requested",
  "assistant": { "name": "Reception" },
  "company": {
    "name": "Jansen Plumbing",
    "website": "https://www.example.com",
    "phone": "+442012345678",
    "email": "info@example.com",
    "address": ""
  },
  "contact": { "name": "A. de Vries", "company": "" },
  "inboundContext": { "customerId": "12345" },
  "postcode": "SW1A 1AA"
}
  • channel is voice, sms, whatsapp or webchat.
  • audioLink is not an audio file but the same link to the conversation in the dashboard, and it is only filled when there is a recording.
  • company.address stays empty as long as your business does not share its address with customers.
  • The language in conversationLink and audioLink is your business language.

Want your own structure, for example because your CRM expects a fixed format? Fill in a body template yourself:

json
{
  "phone": "{{personNumber}}",
  "note": "{{summary}}",
  "source": "Yarla",
  "url": "{{conversationLink}}"
}

What a request after the conversation did is shown in the Inbox on the conversation, under Technical details, at What the actions did. It lists the status code, and on an error also the start of your system's response.

More detail: Webhook after the call.

Recipes for Make, n8n and Zapier ​

You do not need to build your own server. Automation platforms give you a webhook URL that you paste straight into the action:

  1. Create a webhook trigger in your platform: in Make the Custom webhook module, in n8n the Webhook node, in Zapier the Catch Hook trigger. Copy the URL.
  2. In Yarla, create an HTTP request action with When set to After the conversation and method POST, and paste the URL. Leave the body template empty so all variables are sent.
  3. Open Try it out, choose Chat and turn on Perform actions for real. Have a short conversation and say goodbye, so the assistant closes the conversation: only then does the action run. During a spoken call under Call, actions after the conversation do not run. Then let your platform detect the structure of the data.
  4. Map the fields (summary, personNumber, outcome, …) to the next step: a row in a spreadsheet, a card on your project board, a message in your team chat.

For a request before the call your scenario must also respond: use the Webhook response module in Make or the Respond to Webhook node in n8n, and have it return a JSON object within 3 seconds. Worked scenarios are in Make & n8n recipes.

Yarla Help — the guide to your AI phone assistant.