Ваш чат-бот только что собрал номер телефона в 11 вечера у посетителя, который спросил про цены и оставил контакты для обратного звонка. Такая заявка — золото, но только если она попадёт в ваш процесс продаж до утра. Если заявки пылятся в личном кабинете, который никто не открывает, или приходят обычными письмами, которые надо вручную перепечатывать в CRM, половина их ценности испаряется за ночь.
Решение — вебхук: каждый раз, когда чат фиксирует заявку, Pravia доставляет её прямо в вашу систему — в Битрикс24, amoCRM, HubSpot, в таблицу или на ваш собственный сервер. Этот guide показывает оба пути: настройку без кода примерно за двадцать минут и свой endpoint, если у вас есть разработчик. Полный технический справочник — на странице интеграции через вебхуки.
1Что едет из чата в вашу CRM
Когда посетитель делится контактами — потому что чат не смог ответить или потому что человек попросил перезвонить, — Pravia создаёт заявку и тут же отправляет одно структурированное событие на ваш вебхук-адрес. Событие называется lead.created, и в нём всегда один и тот же набор полей: из какого чата и бизнеса пришла заявка, имя посетителя, его контактные данные, о чём он спрашивал, и уникальный ключ, чтобы вы никогда не сохранили одну заявку дважды.
Думайте об этом как о накладной, приложенной к каждой заявке: кто, как связаться, чего хочет, и серийный номер. Ваша задача — дать Pravia адрес, куда доставлять эти накладные, и решить, что происходит по этому адресу. Это и есть вся интеграция — дальше только детали.
Один момент, который стоит знать заранее: на аккаунт Pravia приходится одна подписка на вебхуки, а адрес доставки должен быть защищённым https-адресом. Приватные внутренние адреса блокируются: облачный сервис не дотянется до вашей офисной сети, поэтому endpoint должен жить в открытом интернете.
2Путь А: без кода, через n8n, Make или Zapier
Если разработчика под рукой нет, пропустите заявки через платформу автоматизации. Вы один раз соединяете Pravia с платформой, а платформа перекладывает каждую заявку в Битрикс24 или любую другую CRM. Никаких серверов, никакого кода, а каждую доставку видно в наглядном журнале.
Большинство команд укладываются в полчаса, а наглядная история запусков делает отладку безболезненной: если заявка в CRM выглядит странно, открываете соответствующий запуск и видите, что именно пришло и как было сопоставлено.
3Направляем поток в Битрикс24
Битрикс24 заслуживает отдельного раздела, потому что на нём держится отдел продаж у огромного числа малых бизнесов. Платформа принимает новые заявки через так называемый входящий вебхук: вы создаёте его в настройках Битрикс24 в инструментах разработчика, и Битрикс24 выдаёт длинный URL, указывающий на метод создания лида. Вставьте этот URL шагом назначения в вашем сценарии автоматизации — и каждая заявка из чата будет автоматически становиться лидом в Битрикс24.
Сопоставление полей, которое использует большинство команд, выглядит так:
| Поле лида в Битрикс24 | Заполняем из заявки чата |
|---|---|
| Название | Заявка из чата на сайте, плюс дата |
| Имя | Имя посетителя из события |
| Телефон или e-mail | Контактные данные из события |
| Комментарии | О чём спрашивал посетитель, плюс ссылка на чат |
Два практических совета. Во-первых, всегда кладите исходный вопрос посетителя в комментарии — через полгода именно это предложение подскажет продавцу, горячий это был покупатель или случайный зевака. Во-вторых, решите, кто владеет свежими лидами в Битрикс24, до включения потока: неназначенные лиды гниют независимо от того, какая система их создала. Простое правило распределения в Битрикс24 или уведомления ответственному менеджеру закрывают эту дыру.
Если у вас другая CRM, схема та же один в один — меняется только шаг назначения. У amoCRM, HubSpot и Pipedrive есть шаги создания заявки во всех крупных платформах автоматизации, а входящие поля от Pravia остаются неизменными.
4Путь Б: свой endpoint на бэкенде
Если разработчик есть и нужен полный контроль — своё удаление дублей, обогащение данных или хитрая маршрутизация, — уберите посредника и направьте вебхук Pravia прямо на свой endpoint. Ваш endpoint должен делать четыре вещи, и все четыре несложные.
Во-первых, принимать POST-запросы с JSON-телом по вашему URL и быстро отвечать кодом 200. Pravia ждёт ответа до десяти секунд и повторяет неудачные доставки, поэтому правильная форма такая: сохранить событие, ответить, а тяжёлую работу делать после.
Во-вторых, проверять подпись каждого запроса. Каждая доставка несёт три заголовка: X-Pravia-Signature, X-Pravia-Timestamp и X-Pravia-Event. Подпись выглядит как t=unix-время,v1=шестнадцатеричный-код и считается как HMAC-SHA256 от вашего секрета по строке «время-точка-сырое-тело-запроса». Пересчитайте её у себя и сравните за постоянное время — никогда обычным сравнением строк. Отклоняйте всё старше пяти минут по метке времени, чтобы отсечь повторные запросы. Все детали — на странице интеграции через вебхуки.
В-третьих, убирать дубли по заголовку Idempotency-Key. Повторы означают, что вы можете легитимно получить одну заявку дважды, — сбои сети случаются. Храните каждый обработанный ключ и молча пропускайте повторы. Ключ настоящей заявки всегда выглядит как lead:id-заявки, так что он элементарно отслеживается до кабинета.
В-четвёртых, обращайтесь с секретом как с паролем. Он показывается в кабинете один раз, и любой, кто им владеет, может подделывать доставки на ваш endpoint. Храните его в конфигурации окружения, никогда в исходном коде, и ротируйте из кабинета в тот момент, когда доступ теряет человек из команды, — ротация делается в один клик, и старые подписи сразу перестают работать.
5Проверьте, прежде чем доверять
Как бы вы ни построили принимающую сторону, докажите её работу до того, как объявлять интеграцию отделу продаж. Отправьте тестовое событие из кабинета и убедитесь, что тестовая заявка появилась в CRM со всеми полями на местах: имя в поле имени, а не в комментариях; телефон набираемый, а не обрезанный. Затем соберите одну настоящую заявку сами через виджет на сайте, притворившись клиентом, и проследите её до самой CRM.
Если что-то не сработало, проверьте трёх обычных подозреваемых: URL должен быть https и публично доступен, сценарий должен быть включён (платформы автоматизации обожают оставлять сценарии в черновиках), а проверка подписи должна использовать сырое, нетронутое тело запроса — разбор и повторная сериализация JSON меняют пробелы и ломают подпись. Исправьте эти три пункта, и почти каждая интеграция начинает течь.
Итог
Чат-бот, который собирает контакты, но не умеет их доставлять, — это блокнот, который никто не читает. Один вебхук превращает его в конвейер: чат собрал заявку в полночь, Битрикс24 или ваша CRM держит её к 00:01, а продавец перезванивает утром уже с полным контекстом. Выделите двадцать минут на путь без кода по руководству по вебхукам, один раз сопоставьте поля, проверьте дважды — и больше никогда не перепечатывайте заявки из писем. Если вы ещё выбираете тариф, доставки по вебхукам уже включены в Starter за $9 вместе с 3 000 ежемесячных ответов; смотрите страницу цен и справочник по настройке в документации по интеграции.