web хуки что это
Вебхуки
Механизм вебхуков в МоемСкладе представляет собой мощный и легкий в использовании инструмент для отслеживания изменений в вашем аккаунте. Мы советуем использовать вебхуки, чтобы взаимодействие МоегоСклада с вашим интернет-магазином или приложением в реальном времени, и вы могли избавиться от периодических запросов изменений.
Что такое вебхук?
Непосредственно сам вебхук содержит описание изменения (тип объекта и ссылку на изменившийся объект), которое отправляется на указанный url. Пример тела запроса вебхука:
В чем разница между АПИ и вебхуками
Есть 2 подхода для получения сведений об изменениях в системе: опрос через АПИ (polling) и подписка на вебхуки. Опрос через АПИ предполагает циклические запросы, чтобы получить изменения. Подписка на вебхуки предполагает получение уведомления об изменении в системе. Можно провести следующую аналогию. Предположим вы заказали товар, но его не оказалось в наличии, поэтому вы каждый день звоните в магазин, чтобы узнать о появлении товара, это похоже на опрос через АПИ. Но вы можете просто попросить менеджера в магазине позвонить вам по указанному номеру телефона, когда товар появится, это подписка на вебхуки. Очевидно, что подписка на вебхуки эффективнее и проще, так как гарантируется оперативное получение изменений в системе и меньшая нагрузка на клиентское приложение.
Когда нужно использовать АПИ, а когда вебхук
Несмотря на преимущество использования вебхуков, важно понимать, что подписка на вебхуки это всего лишь форма уведомления об изменениях в системе. Действия с сущностями (CRUD) необходимо выполнять с помощью АПИ.
Возможные сценарии, когда подписка на вебхуки выглядит предпочтительнее опросов через АПИ:
Как использовать вебхуки через JSON API
Вебхуки в JSON API
Работа с вебхуками в МоемСкладе возможна только через JSON API. Методы работы с вебхуками позволяют создать, удалить, обновить, получить и отключить вебхуки.
Ключевыми признаками вебхука являются адрес отправки (url), тип сущности (entityType) и тип события (action). Пара признаков (entityType и action) должна быть уникальной, т.е. не может повторяться в других вебхуках. Существуют следующие типы событий (action):
Данные типы событий могут быть применимы ко всем типам сущностей (базовые сущности и документы). Обратите внимание, что отчеты и аудит не являются сущностями.
Рассмотрим методы работы с вебхуками. Для создания вебхука достаточно указать url, entityType и action, как в примере ниже
В ответ должен придти json, содержащий описание вебхука
Как и в других запросах сущностей JSON API другие действия над вебхуками возможны только при указании идентификатора. В полученном json поле id. Пример получения вебхука по идентификатору.
У вебхука можно изменить поля, указанные при создании, а также включить/отключить его. Для этого выполняется PUT запрос с указанием идентификатора. Пример запроса с изменением события
Пример запроса с отключением вебхука.
Удаление вебхука выполняется по аналогии, но только используется метод DELETE.
Получить все вебхуки можно с помощью типичного GET запроса.
В ответ придет коллекция вебхуков.
Ограничения при работе с вебхуками
При работе с вебхуками есть ряд важных замечаний:
Отправка вебхука в клиентское приложение
МойСклад отправляет вебхук в клиентское приложение с помощью метода POST, указывая заголовок User-Agent со значением MoySklad webhook touch agent 1.0 (/https://www.moysklad.ru).
При отправке уведомления вебхука, МойСклад ожидает ответ от клиентского приложения со статусом 200 или 204, чтобы считать уведомление доставленным. При невалидном ответе от клиентского приложения наша система осуществляет еще 3 попытки отправки. Данные попытки осуществляются последовательно, без таймаутов между ними. Если все попытки закончились неудачно, то данное уведомление считается неотправленным и в дальнейшем удаляется, в клиентское приложение оно отправлено не будет, т.к. проблема на стороне клиентского приложения.
Как проверить, что вебхук работает?
Результаты поиска « код вставки виджета »
Описание API
Инструменты
Методы API — Webhooks
Примеры
Методы API — Пользователи
Методы API — События
Методы API — Оплаты от юрлиц
Методы API — Заказы
Методы API — Словари
Методы API — Организации
Коллбэки и webhooks
Что такое webhook
Webhook — механизм получения уведомлений об определённых событиях на TimePad (в основном о действиях пользователей) на свой собственный сайт.
Например, на TimePad есть webhook, который позволяет отслеживать изменения статусов регистрации пользователей. Он вызывается каждый раз при изменении любого билета вашей организации. По сути происходит вот что: данные регистрации кладутся в JSON и отправляются на URL, указаный в настройках организации.
Как настроить webhook
Для использования достаточно прописать в настройках организации URL, на который будет отправляться POST-запрос.
В поле Ссылка для уведомления нужно оставить адрес, к которому TimePad будет обращаться в случае смены статусов билетов, а в поле Секретная фраза — ключ, которым будет подписано сообщение от TimePad. И не забудьте нажать «Сохранить».
После этого при любой смене статуса билета в вашей организации — например, при регистрации или оплате — будет выполняться POST-запрос на адрес, который вы указали в настройках.
Как прочитать webhook
Пример чтения webhook’а в PHP
Типы вебхуков
Сейчас существует 3 типа вебхуков:
Использование вебхуков по изменению статуса заказа и билета
Вебхуки по заказу и билетам связаны между собой. При любом измении заказа посылается вебхук по заказу и вебхуки по каждому из билетов в заказе.
Данные вебхуки посылаются в случаях:
Содержание JSON запроса для хука изменения статусов заказа
Структура аналогична ответу API по заказам OAuth2. Пример такого json’a:
Содержание JSON запроса для хука изменения статусов билетов
Список возможных статусов билетов
Поля status:name / status_raw в запросе могут содержать следующие значения (в скобках указаны соответствующие значения поля status:title / status )
Как отвечать на webhook
В таких случаях запрос будет отправлен на этот же адрес с теми же данными через час. Если эта попытка тоже не удалась, следующая состоится через сутки. После этого запрос будет удалён из очереди, даже если доставка так и не состоялась. Следите за своими серверами 😉
Проектирование системы, принимающей вебхуки
Разрабатывая систему, принимающую вебхуки, лучше снадбите её логами — какие вебхуки приходили.
Обязательно предусмотрите у себя следующие свойства вебхуков (кстати, все это относится к вебхукам абсолютно любых систем):
Порядок прихода вебхуков не обязательно хронологический
Вебхуки отправляются в множество потоков. Совершенно не исключен тот факт, что какой-то из потоков отправит более поздний вебхук быстрее, чем соседий поток — более ранний. Если нарушение хронологии может вам что-то сильно сломать — проверяйте дату хука (поле hook_generated_at ), сравнивайте её с датой последнего хука по той же сущности, который вы приняли.
Вебхук может не прийти вовсе
Когда отправитель вебхука видит, что отправленный запрос не завершился корректно (HTTP статусом 200 OK), он его обычно переотправляет (еще одно место где может сбиться хронология). Вторая отправка чаще всего завершается успехом.
Один и тот же вебхук может прийти несколько раз
Достаточно часто бывает так, что принимающая сторона на самом деле обработала вебхук и ответила корректным статусом, но отправитель этого ответа не дождался или интерпретировал его неверно (например, при проблемах сети).
В этом случае отправитель сделает повторную попытку отправки вебхука и принимающая сторона будет обязана обработать его корректно – т.е. проигнорировать, но отправить ответ HTTP 200 OK. Вы можете проверять GUID вебхука (поле hook_guid ).
При отправке вебхука есть таймаут
Наш сервер 5 секунд ждет ответа о том, что вебхук обработан. Если вам этого времени может не хватать (много обработки, медленное соединение, высокая нагрузка), используйте механизм очередей — приняв вебхук, ставьте его обработку в очередь и отвечайте, что вебхук принят.
Настройка веб-хуков в сервисе рассылок: полезный инструмент для практического применения
Даже если вы потратили много сил и времени на разработку стратегии емейл маркетинга и ее внедрение, создание цепочек триггерных писем и настройку омниканальных коммуникаций, в один не очень прекрасный момент что-то может пойти не так. Своевременному решению проблем способствует оперативное информирование об их появлении. Чтобы не остаться в неведении о сбоях в графике отправки триггеров, можно настроить веб-хуки.
Как это работает?
Webhooks можно настроить для практически любых типов событий:
Веб-хуки в действии
Настроив веб-хуки, вы сможете на своей стороне получать необходимую информацию без отправки запросов в нашу систему. Например, webhooks необходимы для отслеживания того, работают ли триггеры. Чтобы получать такие уведомления о сбоях, каждому триггеру нужно присвоить свою метку (тег). В массиве JSON эта информация будет передаваться следующим образом: «messageTag»: «AbandonedCart»
По этим меткам можно проанализировать частоту отправок триггеров того или иного вида и своевременно исправить ситуацию, если этот показатель внезапно выйдет за допустимые пределы.
Альтернативный вариант контроля триггеров: пример из практики
Для контроля над частотой отправки триггеров можно использовать не только webhooks. Мы настроили отправку альтернативных уведомлений о сбоях для одного из наших клиентов, и готовы рассказать вам об этом во всех подробностях.
Ниже приводится поэтапная схема внедрения таких уведомлений.
При нажатии на название организации в аккаунте еСпутник появляется выпадающее меню, в котором нужно выбрать пункт “Настройки” (Settings)
Открывается страница настройки уведомлений о сбоях (Notifications settings). С помощью кнопки Add notification создается новое уведомление.
При добавлении нового уведомления нужно заполнить все требуемые поля:
В типе уведомления указать “событие”,
Выбрать из выпадающего списка название события, частоту поступления которого нужно контролировать,
Указать количество событий, которое считаете критичным и период, за который система должна их посчитать;
Выбрать вид создаваемого уведомления (“Warning” или “Alarm”)
Эту последовательность действий нужно повторить для всех триггеров, которые важно держать под контролем. Количество событий, которое является критичным за определенный период времени, может устанавливаться индивидуально для каждого триггера.
Настройка сценариев запуска писем “Warning” и “Alarm”
Для отправки уведомлений “Предупреждение” и “Тревога” создаем стандартные сценарии такого вида:
Используем блок “Обязательный емейл”, так как получатель этих уведомлений не обязательно должен быть подписчиком. Отправку данных сообщений можно настроить на любой электронный адрес (например, руководителя компании, маркетолога, аккаунт менеджера).
В настройках сценария указывается емейл того человека, который должен контролировать корректную работу триггеров, название сообщения, которое должно отправится в случае наступления события.
Создаем письма: делаем правильные акценты
А вот пример самого уведомления:
Как веб-хуки спасают ситуацию
10 из 80-ти триггеров отключились, так как изменились параметры события, которые передавались для запуска сценариев. Так мы своевременно узнали о неполадках в работе триггеров и оперативно их устранили.
Автоматизировать email маркетинг
Настроив уведомление о сбоях, вы не только облегчите себе работу, но и улучшите качество коммуникации со своими подписчиками, так как все запланированные триггера они будут получать в срок.
Что такое вебхуки
В этом материале расскажем про вебхуки: как они используются, где их можно настроить, дадим примеры использования в Mindbox.
Как используются
По сути, это механизм оповещения одной системы о событиях в другой. Несколько примеров использования:
Где можно настроить вебхуки
Функционал вебхуков есть во многих системах: CRM, CDP, мессенджерах — например, в «Битрикс24», Slack или Mindbox. Когда в системе произойдет какое-то событие, настроенный вебхук оповестит об этом событии другую систему. Для этого у другой системы должно быть API, которое позволяет к ней обращаться.
Настройка в Zapier
Для автоматизации передачи данных между двумя системами можно использовать сторонние приложения. Например, Zapier. Оно позволяет настраивать обмен данными между различными приложениями по API с помощью вебхуков.
В CDP Mindbox
В Mindbox вебхуки нужны, чтобы оповещать сторонние системы о событии в платформе. Запросы в стороннюю систему настраиваются через интерфейс. Чтобы вебхук вызывался в нужный момент, достаточно указать его в триггере в качестве одного из шагов, которые выполняются при наступлении события. Примеры использования в Mindbox:
Формат запроса — произвольный, можно адаптировать его под API принимающей системы. В качестве данных можно отправить любую собранную информацию о клиенте, его действиях или заказе.
Интерфейс создания вебхука
Управление находится в меню Администрирование — Интеграции — Вебхуки. Вот пример создания или редактирования в интерфейсе:
После создания вебхук можно сразу использовать в операциях и триггерах:
Если вам интересно в деталях узнать как настроить вебхук в Mindbox, прочтите обучающую статью в нашей базе знаний.
Резюме
Для понимания вебхуков важно запомнить следующее:
Что такое вебхук – webhook? И как его подключить?
Я некоторое время реально не мог понять, что такое вебхук))
Оказалась это совершенно простая технология, поэтому особо никто и не пишет об этом. Сейчас опишу как это работает в связке с моей базой данных на PHP Mysql и в данном случае сайтом на тильде.
Думаю, это применимо и к другим конструкторам. Сам я не люблю конструкторы от слова СОВСЕМ, из за ограничений))), но в силу обстоятельств на моей работе приходится работать с конструкторами.
Вопрос задан не только, чтобы я сам дал на него ответ, но и может есть более интересные решения?
1 ответ 1
На сервере два файла: connect.php и webhook.php
connect.php
в файле коннект прописываем подключение к базе данных.
webhook.php Позже нам его нужно будет поменять, чтоб он отсылал данные в базу данных.
Ваш сайт с файлом: https://example.com/webhook.php (за место этого домена «example.com» должен быть ваш домен) Эта ссылка и есть вебхук, берем эту ссылку и вставляем на сайте от куда отсылаются данные из формы. Сначала вставляем этот тестовый код чтоб получить сообщение об успешном тесте (за место моей почты «anton.strobe@gmail.com» ставим свою)
webhook.php Измененный вебхук.
В этом скрипте происходит два действия:
1) Отправка массива данных сообщением на почту.
2) Добавление данных в базу данных.
Создание базы данных одним действием!