Нода «Вебхук»: подключение своей системы

Универсальная нода: во время разговора вызывает ваш HTTP-сервис, передаёт ему собранные данные и может использовать ответ дальше в сценарии.

Нужна, когда готовой интеграции нет: своя учётная система, отраслевая программа, собственная база, промежуточный сервис вроде no-code-платформы.

Что можно сделать

• Проверить клиента в своей базе — есть ли активный абонемент, была ли предоплата.
• Получить актуальные свободные слоты из своего расписания.
• Отправить заявку в систему, для которой у нас нет коннектора.
• Запустить цепочку в сервисе автоматизации.
• Проверить наличие товара на складе.

Настройка

Адрес. Только https:// — незащищённые адреса не принимаются.

Метод. GET, POST, PUT или PATCH. Для передачи данных обычно POST.

Заголовки. Пары «имя — значение». Здесь задают тип содержимого и признак вашей системы.

Заголовки хранятся в настройках сценария в открытом виде. Не кладите сюда настоящие секреты — токены доступа, ключи API с широкими правами. Если ваш сервис требует авторизации, сделайте отдельный эндпоинт со случайным длинным путём и правом только на нужную операцию, либо поставьте перед ним прослойку, которая уже знает секрет.

Передаваемые данные. Соответствие «поле запроса — переменная сценария». Так ваш сервис получит имя, телефон, услугу и всё остальное, что собрал агент.

Ответ в переменную. Куда положить то, что вернул сервис. Дальше значение можно подставить в реплику или проверить условием.

Фраза ожидания. Что говорить, пока идёт запрос. Задавайте обязательно.

Таймаут. Сколько ждать ответа. Держите небольшим: клиент ждёт в реальном времени, и десять секунд тишины — это очень долго.

Как это выглядит в разговоре

Ограничения безопасности

Запрос уходит не напрямую из звонка, а через нашу инфраструктуру — она проверяет адрес и защищает от обращений внутрь чужих сетей.

Практические следствия:

• Адреса во внутренних сетях недоступны: localhost, 192.168.*, 10.* и подобные не сработают. Сервис должен быть доступен из интернета.
• Только https://.
• Самоподписанные сертификаты не принимаются.

Если ваша система живёт во внутреннем контуре, поставьте наружу тонкий шлюз, который принимает запрос и передаёт внутрь.

Что должен возвращать ваш сервис

Отвечайте быстро и коротко. Вебхук вызывается посреди живого разговора — человек ждёт в трубке.

Хорошо: маленький JSON с плоской структурой и понятными полями, ответ за 200–500 миллисекунд.

Плохо: тяжёлый ответ с вложенностью, генерация отчёта на лету, обращение к медленной внешней системе внутри обработчика.

Если операция долгая по природе — принимайте запрос, отвечайте сразу «принято» и выполняйте её в фоне.

Два выхода

Как у ноды CRM: «получилось» и «ошибка». Ветка ошибки срабатывает при недоступности сервиса, истёкшем таймауте или ответе с ошибкой.

Подключать обязательно. Ваш сервис однажды упадёт — это нормально; ненормально, если из-за этого оборвётся разговор с клиентом.

Что делать нельзя

Класть в вебхук критичную логику без запасного плана. Если без ответа сервиса разговор бессмысленен, продумайте, что агент скажет при сбое.

Вызывать несколько вебхуков подряд. Каждый — это пауза. Два подряд — пять секунд тишины. Сведите к одному запросу на своей стороне.

Передавать лишние персональные данные. Отправляйте только то, что нужно для операции. Это и требование закона, и просто здравый смысл.

Отладка

Начните с бесплатного сервиса-приёмника запросов (их много, ищутся по запросу «webhook tester»): укажите его адрес, сделайте тест-звонок и посмотрите, что реально ушло. Так вы отделите проблемы сценария от проблем своего сервиса.

Дальше — на своём адресе, с логированием входящих запросов.