Пока данные о звонке лежат внутри робота, для остальных систем клиники их как бы нет: CRM не знает о новой записи, мессенджер не отправит подтверждение, руководитель не увидит всплеск отказов. Вебхуки решают это — робот сам сообщает внешним системам о каждом событии в момент, когда оно происходит. Разбираем, что такое вебхуки простыми словами, какие события шлёт робот и как построить на них автоматизацию без ручного экспорта.
Вебхук — это автоматическое сообщение, которое робот отправляет внешней системе в момент события: пациент записался, звонок завершился, обзвон дал отказ. Вместо того чтобы клиника периодически спрашивала «что нового», робот сам присылает данные, как только они появились. Задержка — доли секунды.
Это переворачивает логику интеграции: не система тянет данные по расписанию, а робот их отдаёт по факту события. Поэтому CRM, мессенджеры и дашборды обновляются мгновенно, без выгрузок и опроса.
Разберём, чем вебхук отличается от обычной интеграции, какие события шлёт робот и что на них можно построить.
Вебхук работает как звонок в дверь: произошло событие — робот тут же стучится на заданный адрес клиники и передаёт данные о нём. Клинике не нужно постоянно проверять, не появилось ли что-то новое; уведомление приходит само. Это самый быстрый способ доставки данных — задержка измеряется миллисекундами.
Альтернатива вебхукам — опрос по расписанию, когда система раз в минуту или в час спрашивает робота о новостях. Такой опрос всегда отстаёт и грузит обе стороны лишними запросами.
Вебхук отдаёт данные ровно один раз и ровно тогда, когда они нужны, — в момент события. Поэтому его и выбирают для реального времени.
Робот шлёт вебхуки по ключевым событиям: входящий звонок начался и завершился, пациент записался, перенёс или отменил визит, обзвон дал результат — дозвон, отказ, недозвон. Каждое событие приходит с данными: телефон, услуга, время, итог. Набор событий выбирает клиника под свои процессы.
Такой поток событий покрывает всю жизнь звонка: от поднятия трубки до итогового статуса. На каждом из них можно повесить своё действие во внешней системе.
Клиника подписывается только на нужные события, чтобы не получать лишний шум — например, только на «записался» и «отказ», если этого достаточно.
В теле вебхука робот передаёт структурированные данные события: номер телефона пациента, услугу или врача, время записи, источник обращения, итог разговора и ссылку на запись. Формат машиночитаемый, поэтому принимающая система сразу раскладывает поля куда нужно. Ничего парсить вручную не приходится.
Состав полей стабильный: система клиники может рассчитывать, что в каждом событии «записался» будут телефон, услуга и слот. Это делает обработку предсказуемой.
Персональные данные в вебхуках передаются по защищённому каналу и в минимальном необходимом объёме — по требованиям к обработке ПДн.
Чтобы принимать вебхуки, клиника указывает роботу адрес — точку, куда слать события. Это может быть готовый обработчик в CRM, сценарий в конструкторе автоматизаций или простой скрипт. Робот начинает слать события на этот адрес сразу после настройки, обычно в тот же день.
Многие клиники используют промежуточный сервис-конструктор, который принимает вебхук и раскладывает его по нужным системам без программирования. Это самый быстрый путь для команды без разработчиков.
Если у клиники есть разработчик, обработчик пишется под свою логику за 2-3 часа — формат событий стабилен и документирован.
На вебхук удобно вешать автозадачи: пришло событие «отказ» — создаётся задача перезвонить, пришло «записался» — уходит подтверждение пациенту. Действие срабатывает в ту же секунду, когда завершился звонок, поэтому реакция клиники мгновенная. Это убирает задержку между звонком и следующим шагом.
Уведомления работают так же: событие «горячий лид» может сразу упасть менеджеру в мессенджер, а «всплеск жалоб» — руководителю. Никто не узнаёт о проблеме постфактум из отчёта.
Как связать звонки с мессенджером для таких уведомлений, разобрано в материале про как соединить звонки и Telegram.
Вебхуки убирают ручной экспорт: как только звонок завершился, его данные уже в CRM — контакт, сделка, итог. Администратору не нужно копировать ничего из отчётов робота в карточки. Это экономит время и исключает потери при переносе, которых при ручном экспорте набегает по 10-20%.
Поскольку данные приходят по событию, а не пачкой в конце дня, CRM всегда актуальна: менеджер видит лид через секунды после звонка, а не наутро.
Такая доставка — основа для честной аналитики: в CRM попадают все события, а не выборка, которую успели перенести руками.
События вебхуков — это сырьё для сквозной аналитики: каждое из них несёт источник, время и итог, поэтому путь пациента от рекламы до записи собирается автоматически. Аналитическая система складывает события в воронку без ручного сведения выгрузок. Данные при этом полные — учтён каждый звонок.
Без вебхуков сквозная аналитика опирается на периодические выгрузки и теряет часть событий в окнах между ними. Поток в реальном времени закрывает эти дыры.
Как выстроить путь от рекламы до визита и оплаты, описано в статье про подключение к сквозной аналитике.
Если система клиники не приняла вебхук — была недоступна или ответила ошибкой, — робот повторяет отправку в течение примерно 15 минут, пока событие не будет доставлено. Это защищает от потери данных при кратком сбое на стороне клиники. Событие не исчезает, а ждёт, пока приёмник снова заработает.
Приёмник подтверждает получение ответом, и только тогда робот считает событие доставленным. Схема с повторами и подтверждением — стандарт надёжных вебхуков.
Клинике стоит убедиться, что её обработчик отвечает быстро и корректно, иначе робот будет слать повторы без нужды.
Вебхуки с медицинскими данными защищают на нескольких уровнях: передача идёт по шифрованному каналу, приёмник проверяет подпись, чтобы убедиться, что запрос действительно от робота, а состав данных сводится к минимуму. Так исключён и перехват, и подделка событий. Это требование к обработке персональных данных.
Проверка подписи критична: без неё на адрес клиники мог бы слать данные кто угодно. Подпись гарантирует источник события.
Юридические рамки работы с ПДн в звонках разобраны в материале про 152-ФЗ и голосовые боты.
Разница в направлении: при работе через API клиника сама запрашивает данные у робота, когда они ей нужны, а вебхук — это когда робот сам присылает данные по событию. Оба механизма дополняют друг друга: вебхук уведомляет о событии, а через API можно дозапросить детали. Вместе они покрывают любую интеграцию.
Для реального времени вебхук эффективнее: не нужно опрашивать робота вхолостую и ждать следующего цикла опроса. Событие приходит ровно тогда, когда произошло.
API удобнее, когда данные нужны по запросу пользователя, а не по факту события, — например, показать историю звонков в карточке.
На вебхуках строят типовые сценарии: подтверждение записи пациенту сразу после звонка, задача менеджеру по горячему лиду, уведомление руководителю о всплеске отказов, запуск цепочки «не дозвонились → сообщение». Каждый сценарий — это событие плюс действие, и настраивается он без программирования в конструкторе.
Ценность в том, что реакция мгновенная и одинаковая для каждого звонка: правило не устаёт и не забывает, в отличие от администратора в час пик.
Начинать стоит с одного-двух сценариев, которые закрывают самую больную потерю, и расширять по мере отладки.
Начните с выбора событий, которые реально меняют процесс: чаще всего это «записался», «отказ» и «недозвон». Определите, какое действие должно происходить на каждом, и укажите роботу адрес приёма. Первые события начнут приходить в тот же день, и автоматизацию можно проверить на тестовых звонках.
Не пытайтесь подписаться на всё сразу — лишние события создают шум и усложняют отладку. Лучше добавить их позже, когда базовые сценарии заработают.
Протестировать поток событий можно бесплатно 7 дней без карты и посмотреть, как данные звонков приходят в реальном времени.
7 дней бесплатно, без карты. Подключение к вашему номеру за 15 минут.