Главная · Блог · HTTP-запрос из чат-бота: как отправить заявку в таблицу, CRM или на свой сервер

HTTP-запрос из чат-бота: как отправить заявку в таблицу, CRM или на свой сервер

· Команда ЧБТ · Интеграции, Сценарии

Бот собрал имя и телефон — дальше заявка должна оказаться там, где с ней работают: в таблице менеджера, в CRM или в системе заказов. Для этого в сценарии ЧБТ есть «Действие» с типом «HTTP-запрос». Оно одним запросом отправляет карточку клиента и переменные диалога на адрес, который вы укажете, а ответ сервера может вернуть обратно в сценарий. Разбираем, что именно уходит, как подключить таблицу или Make и где бот такого не сделает.

Что делает «HTTP-запрос» и когда он нужен

«HTTP-запрос» — это вызов чужого адреса прямо из сценария: бот дошёл до блока, отправил данные и пошёл дальше. Он нужен, когда заявке мало оказаться в разделе «Контакты» ЧБТ:

  • Таблица менеджера. Каждая заявка — новая строка в Google Таблице, без выгрузок CSV.
  • CRM без нативной интеграции. amoCRM, Битрикс24 и другие подключаются через сервисы-посредники вроде Make или Albato: бот отправляет данные на их вебхук, а сценарий посредника создаёт сделку. Нативных коннекторов к этим CRM в ЧБТ нет — честно об этом на странице интеграций.
  • Свой сервер. Проверить номер заказа, остаток на складе или статус записи и показать ответ клиенту.

Если нужна только воронка заявок без внешних систем, хватит встроенной CRM: «Действие» → «Сделка в CRM» заводит сделку без всякого кода.

Как добавить запрос в сценарий

  1. Откройте сценарий и поставьте блок «Действие» после шага, где бот уже собрал данные, — обычно после «Сбора данных» с телефоном.
  2. Выберите тип «HTTP-запрос».
  3. Укажите метод и адрес. Методы — GET, POST, PUT, PATCH и DELETE; если не выбрать, уйдёт POST. Для отправки заявки почти всегда нужен POST.
  4. Если ответ сервера нужен дальше в диалоге, впишите имя переменной в поле «В переменную», например order_status. Потом её можно вывести в «Сообщении» или проверить «Условием».
  5. Сохраните и включите сценарий.

Один нюанс: в тест-чате запрос не отправляется — чтобы проверка сценария не создавала тестовые заявки в чужой системе. Переменная из «В переменную» в тест-чате будет пустой. Проверять доставку нужно настоящим сообщением боту, а результат смотреть в журнале (о нём ниже).

Что именно уходит на ваш адрес

У методов POST, PUT и PATCH тело запроса — JSON такого вида:

{
  "contact": {
    "id": 1204,
    "name": "Анна",
    "phone": "+79161234567",
    "email": "",
    "tags": ["qr-kassa"],
    "fields": { "услуга": "Маникюр" }
  },
  "vars": { "date": "пятница" },
  "text": "пятница после 18",
  "channelType": "telegram"
}
  • contact — карточка клиента: имя, телефон, почта, теги и поля, которые записал «Сбор данных» или «Записать в поле контакта». Телефон и почта приходят, даже если вы не сохраняли их в переменную.
  • vars — переменные текущего диалога.
  • text — последнее сообщение клиента.
  • channelType — откуда клиент: telegram, max, vk или web.

У GET и DELETE тела нет — данные такому адресу не передаются, поэтому для отправки заявки они не подходят.

Заявка в Google Таблицу

Таблица сама по себе запросы не принимает — нужен небольшой скрипт Google Apps Script, опубликованный как веб-приложение. Он принимает JSON и дописывает строку:

function doPost(e) {
  const d = JSON.parse(e.postData.contents);
  SpreadsheetApp.getActive().getSheetByName('Заявки')
    .appendRow([new Date(), d.contact.name, d.contact.phone, d.text, d.channelType]);
  return ContentService.createTextOutput('ok');
}
  1. В таблице: «Расширения» → «Apps Script», вставьте код, создайте лист «Заявки».
  2. «Начать развёртывание» → «Веб-приложение», доступ — «Все». Скопируйте адрес вида https://script.google.com/macros/s/…/exec.
  3. В ЧБТ — «Действие» → «HTTP-запрос», метод POST, этот адрес.

Важная особенность Google: на POST веб-приложение отвечает перенаправлением. ЧБТ перенаправлениям не следует, поэтому в журнале будет код 302, а вместо ответа «ok» в переменную попадёт служебная страница перенаправления — не выводите эту переменную клиенту. Строка в таблице при этом добавляется — проверьте таблицу после первой заявки. Если ответ скрипта нужен в диалоге, ставьте посредника (Make, Albato) — они отвечают обычным 200.

Ответ сервера — обратно в диалог

Поле «В переменную» превращает запрос в вопрос к вашей системе. Пример — статус заказа из вашей учётной системы:

  1. «Сбор данных» спрашивает номер заказа и сохраняет его в переменную order.
  2. «HTTP-запрос» POST на ваш адрес, «В переменную» — status. Сервер берёт vars.order и отвечает текстом: «Заказ собран, курьер приедет завтра».
  3. «Сообщение» выводит {{status}}.

В переменную попадает тело ответа целиком, до 10 КБ, — поэтому лучше, чтобы сервер отвечал готовой фразой для клиента, а не большим JSON. Если сервер не ответил за 15 секунд или адрес недоступен, переменная останется пустой: поставьте после запроса «Условие» на пустое значение и предложите оператора. Если сервер ответил ошибкой (код 400 или 500), в переменную попадёт текст этой ошибки — поэтому надёжнее проверять «Условием» ожидаемый ответ, а не только пустоту.

Журнал HTTP-запросов: как понять, дошла ли заявка

Владелец и администратор проекта видят «Журнал HTTP-запросов» — кнопка появляется в разделе «Сценарии», когда в проекте есть хотя бы один такой блок. В журнале по каждому запросу: когда, из какого сценария, метод и адрес, код ответа, время и начало ответа или причина отказа. Так проще всего отличить «заявка не дошла» (нет кода, ошибка соединения) от «дошла, но сервер ответил ошибкой» (код 400 или 500).

Ограничения, которые стоит знать заранее

  • Нет своих заголовков и авторизации. Запрос уходит с заголовками Content-Type и User-Agent — добавить токен или ключ API нельзя. Адреса, которые требуют заголовок авторизации, напрямую не подойдут: нужен посредник или свой адрес-приёмник с секретом в пути.
  • Повтора при сбое нет. Если чужой сервер не ответил, ЧБТ не отправляет запрос второй раз — иначе внешняя система могла бы получить дубль заказа. Пропуск виден в журнале.
  • Перенаправления не выполняются, а внутренние и служебные адреса (локальная сеть, 127.0.0.1 и подобные) запрещены из соображений безопасности.
  • Ответ до 10 КБ и ожидание до 15 секунд.
  • Обратный путь — отдельно. Чтобы ваша система сама запускала бота (например, отправить клиенту статус), нужен не этот блок, а входящий вебхук — справка по вебхукам.

Make, Albato и другие посредники: как связать бота с CRM

Если CRM требует ключ API в заголовке, напрямую блок «HTTP-запрос» её не вызовет — своих заголовков у него нет. Обходной путь, который работает почти с любой системой, — сервис-посредник:

  1. В Make (или Albato, Zapier-аналоге) создайте сценарий с модулем «Webhook» — он даст адрес приёмника.
  2. Вставьте этот адрес в «HTTP-запрос», метод POST, и отправьте боту тестовую заявку из мессенджера. Посредник увидит JSON и предложит разобрать поля: contact.name, contact.phone, contact.fields, channelType.
  3. Следующим модулем добавьте действие CRM — «Создать сделку» в amoCRM или «Добавить лид» в Битрикс24 — и сопоставьте поля. Ключи и токены CRM хранятся у посредника, а не в боте.

Плюс посредника — он сам умеет повторять запросы к CRM, если та временно недоступна, и ведёт свой журнал. Минус — ещё один сервис и, как правило, отдельная подписка.

Что лучше передавать: поля карточки или переменные

У запроса два источника данных, и путать их не стоит:

  • Поля карточки (contact) — то, что останется с клиентом навсегда: имя, телефон, почта, теги, поля анкеты. «Сбор данных» записывает телефон и почту в карточку всегда, даже без «В переменную». Для CRM почти всегда нужно именно это.
  • Переменные (vars) — то, что живёт в текущем диалоге: выбранная услуга, дата, номер заказа. Если значение нужно и после диалога, запишите его в поле карточки действием «Записать в поле контакта» — тогда оно придёт в contact.fields.

Практическое правило: всё, что менеджер должен увидеть в CRM, кладите в поля карточки, а переменные используйте для логики внутри сценария.

Как защитить свой адрес-приёмник

Адрес, на который бот шлёт заявки, может узнать кто угодно, кто его увидит, — а значит, и отправить туда мусор. Раз заголовка авторизации у запроса нет, защищайтесь так:

  • сделайте адрес длинным и случайным, с секретом в пути: https://example.ru/hooks/chbt/9f2c…;
  • на сервере проверяйте, что пришёл JSON нужной формы — с contact и channelType;
  • не выводите ответ сервера клиенту целиком, если в нём могут быть служебные данные: отвечайте готовой фразой.

Чеклист перед запуском

  1. Блок стоит после шага, где собран телефон или нужные поля.
  2. Метод — POST (или PUT/PATCH), не GET.
  3. Адрес открыт без авторизации или это вебхук посредника.
  4. После запроса есть «Условие» на пустую переменную — на случай, если сервер не ответил.
  5. Проверка — настоящим сообщением боту из мессенджера, результат — в «Журнале HTTP-запросов» и в самой таблице или CRM.

Ещё в блоге