Home · Blog · HTTP request from a chatbot: how to send a lead to a spreadsheet, CRM or your own server

HTTP request from a chatbot: how to send a lead to a spreadsheet, CRM or your own server

November 2, 2026 · Command CHBT · Integrations, Flows

The bot has collected a name and a phone number — now the lead has to land where people work with it: in a manager's spreadsheet, in a CRM or in an order system. For this, a CHBT flow has an “Action” of the “HTTP request” type. In one request it sends the customer card and the conversation variables to the address you specify, and it can bring the server's response back into the flow. We look at what exactly is sent, how to connect a spreadsheet or Make, and what the bot cannot do here.

What the “HTTP request” does and when you need it

An “HTTP request” is a call to someone else's address right from the flow: the bot reaches the block, sends the data and moves on. You need it when it is not enough for a lead to end up in the CHBT “Contacts” section:

A manager's spreadsheet. Every lead is a new row in a Google Sheet, with no CSV exports.
A CRM without a native integration. amoCRM, Bitrix24 and others are connected through intermediary services such as Make or Albato: the bot sends data to their webhook, and the intermediary's scenario creates a deal. CHBT has no native connectors to these CRMs — we say so openly on the integrations page.
Your own server. Check an order number, stock in a warehouse or an appointment status and show the answer to the customer.

If all you need is a lead pipeline without external systems, the built-in CRM is enough: “Action” → “Transaction in CRM” creates a deal without any code.

How to add a request to a flow

Open the flow and place an “Action” block after the step where the bot has already collected the data — usually after “Data collection” with the phone number.
Choose the “HTTP request” type.
Specify the method and the address. The methods are GET, POST, PUT, PATCH and DELETE; if you do not choose one, POST is sent. To send a lead you almost always need POST.
If the server's response is needed later in the conversation, enter a variable name in the “To variable” field, for example order_status. You can then show it in a “Message” or check it with a “Condition”.
Save and enable the flow.

One nuance: in the test chat the request is not sent — so that testing the flow does not create test leads in someone else's system. The variable from “To variable” will be empty in the test chat. Check delivery with a real message to the bot and look at the result in the log (more on it below).

What exactly is sent to your address

For POST, PUT and PATCH the request body is JSON like this:

{
  "contact": {
    "id": 1204,
    "name": "Anna",
    "phone": "+79161234567",
    "email": "",
    "tags": ["qr-kassa"],
    "fields": { "service": "Manicure" }
  },
  "vars": { "date": "Friday" },
  "text": "Friday after 6 pm",
  "channelType": "telegram"
}

contact — the customer card: name, phone, email, tags and the fields written by “Data collection” or “Save to contact field”. The phone and email arrive even if you did not save them to a variable.
vars — the variables of the current conversation.
text — the customer's last message.
channelType — where the customer is: telegram, max, vk or web.

GET and DELETE have no body — no data is passed to such an address, so they are not suitable for sending a lead.

A lead in Google Sheets

A spreadsheet does not accept requests on its own — you need a small Google Apps Script published as a web app. It accepts the JSON and appends a row:

function doPost(e) {
  const d = JSON.parse(e.postData.contents);
  SpreadsheetApp.getActive().getSheetByName('Leads')
    .appendRow([new Date(), d.contact.name, d.contact.phone, d.text, d.channelType]);
  return ContentService.createTextOutput('ok');
}

In the spreadsheet: “Extensions” → “Apps Script”, paste the code and create a “Leads” sheet.
“Deploy” → “Web app”, access — “Anyone”. Copy the address like https://script.google.com/macros/s/…/exec.
In CHBT — “Action” → “HTTP request”, method POST, this address.

An important Google quirk: the web app answers a POST with a redirect. CHBT does not follow redirects, so the log will show code 302, and instead of the “ok” response the variable will get the service redirect page — do not show this variable to the customer. The row is still added to the spreadsheet — check the sheet after the first lead. If you need the script's response in the conversation, use an intermediary (Make, Albato) — they answer with a normal 200.

The server's response — back into the conversation

The “To variable” field turns the request into a question to your system. Example — an order status from your accounting system:

“Data collection” asks for the order number and saves it to the variable order.
“HTTP request” POST to your address, “To variable” — status. The server takes vars.order and answers with text: “Your order is packed, the courier will come tomorrow”.
A “Message” shows {{status}}.

The whole response body goes into the variable, up to 10 KB — so it is better if the server answers with a ready phrase for the customer rather than a large JSON. If the server did not answer within 15 seconds or the address is unavailable, the variable stays empty: put a “Condition” on an empty value after the request and offer an operator. If the server answered with an error (code 400 or 500), the variable will get the text of that error — so it is safer to check the expected answer with a “Condition”, not just emptiness.

HTTP request log: how to tell whether the lead arrived

The project owner and administrator see the “HTTP request log” — the button appears in the “Flows” section when the project has at least one such block. For each request the log shows when it happened, which flow it came from, the method and address, the response code, the time and the beginning of the response or the reason for the failure. This is the easiest way to tell “the lead did not arrive” (no code, connection error) from “it arrived, but the server returned an error” (code 400 or 500).

Limits worth knowing in advance

No custom headers and no authorization. The request goes out with the Content-Type and User-Agent headers — you cannot add a token or an API key. Addresses that require an authorization header will not work directly: you need an intermediary or your own receiving address with a secret in the path.
No retry on failure. If the other server did not answer, CHBT does not send the request a second time — otherwise the external system could get a duplicate order. The miss is visible in the log.
Redirects are not followed, and internal and service addresses (local network, 127.0.0.1 and the like) are blocked for security reasons.
Response up to 10 KB and a wait of up to 15 seconds.
The way back is separate. For your system to trigger the bot itself (for example, to send a customer a status), you need not this block but an incoming webhook — help on webhooks.

Make, Albato and other intermediaries: how to connect the bot to a CRM

If a CRM requires an API key in a header, the “HTTP request” block cannot call it directly — it has no custom headers. A workaround that works with almost any system is an intermediary service:

In Make (or Albato, or a Zapier-like service) create a scenario with a “Webhook” module — it will give you a receiving address.
Paste this address into the “HTTP request”, method POST, and send the bot a test lead from the messenger. The intermediary will see the JSON and offer to parse the fields: contact.name, contact.phone, contact.fields, channelType.
As the next module add a CRM action — “Create deal” in amoCRM or “Add lead” in Bitrix24 — and map the fields. The CRM keys and tokens are stored with the intermediary, not in the bot.

The plus of an intermediary is that it can retry requests to the CRM if it is temporarily unavailable and keeps its own log. The minus is one more service and, as a rule, a separate subscription.

What to pass: card fields or variables

The request has two data sources, and it is worth not mixing them up:

Card fields (contact) — what stays with the customer for good: name, phone, email, tags, form fields. “Data collection” always writes the phone and email to the card, even without “To variable”. For a CRM this is almost always what you need.
Variables (vars) — what lives in the current conversation: the chosen service, a date, an order number. If a value is needed after the conversation too, write it to a card field with the “Save to contact field” action — then it will arrive in contact.fields.

A practical rule: put everything the manager must see in the CRM into card fields, and use variables for logic inside the flow.

How to protect your receiving address

Anyone who sees the address the bot sends leads to can learn it — and send junk there. Since the request has no authorization header, protect yourself like this:

make the address long and random, with a secret in the path: https://example.ru/hooks/chbt/9f2c…;
on the server check that JSON of the expected shape arrived — with contact and channelType;
do not show the server's response to the customer in full if it may contain service data: answer with a ready phrase.

Checklist before launch

The block is placed after the step where the phone or the required fields are collected.
The method is POST (or PUT/PATCH), not GET.
The address is open without authorization or is an intermediary's webhook.
After the request there is a “Condition” on an empty variable — in case the server did not answer.
Test with a real message to the bot from the messenger; check the result in the “HTTP request log” and in the spreadsheet or CRM itself.

Integrations and APIs Help: webhooks CRM and contacts Leads from a bot in CRM Collecting applications via chatbot