Под вебхуком понимается реакций стороннего по отношению Битрикс24 приложения – как правило некоторого PHP – файла – на событие его запуска. Это событие может быть вызвано из Битрикс24 через инициализацию данного файла (исходящий вебхук) или открытия данного файла на стороне стороннего сервера с вызовом методов REST API (входящий вебхук). Допускается и очень часто применяется комбинация исходящего и входящего вебхука.
Вебхуки настраиваются в разделе приложений Битрикс24, также на них можно сослаться из роботов \ триггеров сущностей CRM \ задач, выполнить запуск исходящего вебхука из бизнес-процесса. При этом сам вебхук представляет собой всего лишь гиперссылку: входящий содержит адрес корпоративного портала, ключ авторизации, и вызываемый метод REST API. Исходящий вебхук – это всего лишь ссылка на сторонний сайт, работающий в https – режиме, куда передается некоторый набор данных в виде POST-запроса.
Вебхуки представляют из себя предельно простой инструмент интеграции – для вызова методов REST API не надо проходит ресурсоемкую процедуру регистрации нового внешнего приложения, задействовать механизмы авторизации по протоколу OATH 2.0. Средством авторизации выступает уникальный ключ, хранящийся в ссылке входящего и запросе исходящего вебхука, в целях безопасности эти ключи рекомендуется периодически обновлять.
Как можно догадаться, вебхуки дают нам мощную свободу действий, ограниченную лишь библиотекой методов REST API. Приведем возможные кейсы применения вебхуков.
Как видим большая свобода действий в применении вебхуков обусловлена следующими причинами: возможность делать стыковки со сторонними системами, поддерживающие функционал веб-сервисов, использованием при вызове вебхуков богатства функций языка PHP (массивов, циклов, условных операторов, собственных объектов, классов и их методов).
Скрипты входящих вебхуков предельно легко отлаживать (запускать скрипт в адресной строке и выводить результат выполнения с помощью команды print_r), их можно ставить на обработку в пакетномм режме через cron.
С другой стороны нельзя забывать про ограничения вебхуков: невозможность создавать через них массово тиражируемые решения с выкладкой на маркетплейс Битрикс24, необходимость в целях безопасности периодической замены ключей авторизации.
Вебхуки настраиваются в разделе приложений Битрикс24, также на них можно сослаться из роботов \ триггеров сущностей CRM \ задач, выполнить запуск исходящего вебхука из бизнес-процесса. При этом сам вебхук представляет собой всего лишь гиперссылку: входящий содержит адрес корпоративного портала, ключ авторизации, и вызываемый метод REST API. Исходящий вебхук – это всего лишь ссылка на сторонний сайт, работающий в https – режиме, куда передается некоторый набор данных в виде POST-запроса.
Вебхуки представляют из себя предельно простой инструмент интеграции – для вызова методов REST API не надо проходит ресурсоемкую процедуру регистрации нового внешнего приложения, задействовать механизмы авторизации по протоколу OATH 2.0. Средством авторизации выступает уникальный ключ, хранящийся в ссылке входящего и запросе исходящего вебхука, в целях безопасности эти ключи рекомендуется периодически обновлять.
Как можно догадаться, вебхуки дают нам мощную свободу действий, ограниченную лишь библиотекой методов REST API. Приведем возможные кейсы применения вебхуков.
| Кейс | Вариант реализации | Комментарий |
| При изменении ответственного в сделке заменить ответственного в связанных с ним задачах | Связать событие обновления сделки с исходящим вебхуком, вызывающим входящие вебхуки: по запросу данных полей сделке, связанных со сделкой задачах, обновлению данных задач, если там другой ответственный | Данный вебхук готовы предоставить читателям данной статьи по запросу |
| Сменить стадию в сделке с «Товар отгружается» на «Товар отгружен клиенту» при поступлении информации из сторонней системы | На стадию сделки «Товар отгружен клиенту» вешается триггер со ссылкой на входящий вебхук, который запускается из логистической системы с параметрами указанной сделки | |
| Автоматически поставить задачу с заполнением чек – листа при переходе лида на новую стадию | Робот перехода сделки на новую стадию связывается с соответствующим входящим вебхуком | |
| При закрытии задачи приема сотрудника на работу в систему выпуска пропусков передается информация о новом сотруднике, указанном в постановщике по задаче | С событием обновления задачи связывается вебхук, проверяющий была ли задача закрыта, соответствует ли она задаче приема сотрудника на работу и передающий информацию по этому сотруднику в систему заказа пропусков | |
| Компания, организующая корпоративное мероприятие, ставит из своей системы событие в календари участников данного мероприятия | Из информационной системы компании, организующей корпоративное мероприятие, вызывается входящий вебхук, который добавляет данные в календари его участников на Битрикс24 | |
| Необходимо наполнить базу CRM при запуске корпоративного портала, одновременно создав контакты, компании и связанные с ними лиды и сделки | Запускается PHP-файл, забирающий сведения из источника и добавляющий сведения на корпоративный портал с помощью серии входящих вебхуков | Методы REST API имеет ограничение на число добавляемых записей в 50 штук. Для выполнения задачи необходимо вызывать серию методов в пакетном режиме |
Как видим большая свобода действий в применении вебхуков обусловлена следующими причинами: возможность делать стыковки со сторонними системами, поддерживающие функционал веб-сервисов, использованием при вызове вебхуков богатства функций языка PHP (массивов, циклов, условных операторов, собственных объектов, классов и их методов).
Скрипты входящих вебхуков предельно легко отлаживать (запускать скрипт в адресной строке и выводить результат выполнения с помощью команды print_r), их можно ставить на обработку в пакетномм режме через cron.
С другой стороны нельзя забывать про ограничения вебхуков: невозможность создавать через них массово тиражируемые решения с выкладкой на маркетплейс Битрикс24, необходимость в целях безопасности периодической замены ключей авторизации.