> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/webhook-node.md). # Вебхук Отправляйте HTTP POST-запросы во внешние API, когда IoT Logic получает данные устройства. Формируйте пользовательские JSON-пакеты со статическими значениями и динамическими атрибутами телеметрии. ## Технический обзор и возможности {% columns %} {% column width="58.333333333333336%" %} **Вебхук** Узел обеспечивает запуск в реальном времени определённых действий во внешних системах. Он отправляет HTTP POST-запросы в указанные конечные точки при получении данных от подключённых узлов. Затем он формирует пользовательские JSON-данные с статическими и динамическими атрибутами и выполняет API-вызовы к сторонним сервисам. {% endcolumn %} {% column width="41.666666666666664%" %}
{% endcolumn %} {% endcolumns %} Узел расширяет возможности IoT Logic за пределы обработки и передачи данных, обеспечивая прямую интеграцию с платформами обмена сообщениями, системами ERM и CRM, а также пользовательскими приложениями для запуска автоматизированных действий на основе вашей конфигурации потока. {% hint style="info" %} Узлы Вебхука настраиваются отдельно для каждого потока в интерфейсе платформы Navixy. Узлы Вебхука служат конечными точками в потоке и для работы требуют как минимум одного входящего соединения. Они не могут передавать данные следующим узлам. {% endhint %}
### Как работают узлы Вебхука Когда данные поступают в узел Вебхука через входящее соединение, он немедленно выполняет HTTP POST-запрос к настроенной конечной точке. Узел: 1. Собирает текущие значения всех атрибутов из подключённых вышестоящих узлов 2. Заменяет ссылки на динамические атрибуты (например, `{{speed}}`) на фактические значения из входящего сообщения 3. Формирует полный JSON-пакет, сохраняя заданную вами структуру 4. Отправляет HTTP POST-запрос с указанными заголовками в целевую конечную точку 5. Продолжает работу, не дожидаясь ответа, позволяя потоку немедленно продолжиться Вебхук срабатывает один раз для каждого сообщения, которое до него доходит. Если несколько параллельных ветвей отправляют данные в Вебхук, он срабатывает отдельно для каждого входящего сообщения. Это срабатывание происходит независимо, не блокируя другие узлы в потоке, и обеспечивает непрерывную обработку данных независимо от времени отклика внешней системы. Каждый **Вебхук** результат срабатывания узла отображается в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md) как атрибут с именем, совпадающим с **ID узла** (показывается в диалоговом окне настройки узла, например `вебхук_1a2b3c4d`). Значение — `0` когда Узел не сработал и `1` когда это произойдёт, позволяя вам подтверждать доставку и различать несколько узлов Вебхук в одном потоке. ### Интеграция в архитектуру потока Узлы Вебхук выполняют роль конечных точек, которые преобразуют обработанные данные устройства во внешние вызовы API. Вместо того чтобы непрерывно передавать все данные устройства, как это делают узлы Узел передачи данных, Вебхук выполняют целевые запросы API с точно настроенными полезными нагрузками. Такая архитектура позволяет: * **Автоматизации на основе событий**: Запускайте внешние рабочие процессы на основе условий устройства, вычисленных показателей или определённых шаблонов данных, выявленных ранее в потоке * **Выборочная передача данных**: Отправляйте только релевантные атрибуты во внешние системы, сокращая ненужную передачу данных и расходы на API * **Параллельное выполнение**: Работает параллельно с другими выходными узлами, позволяя одновременно срабатывать Вебхукам и непрерывно передавать данные в разные точки назначения * **Интеграция из нескольких источников**: Принимайте входящие соединения из нескольких параллельных ветвей и получайте доступ к атрибутам всех подключенных узлов ### Возможности узла Блок **Узел Вебхук** предоставляет: * **Выполнение HTTP POST**: Отправляет настраиваемые HTTP POST-запросы на любую доступную конечную точку по протоколам HTTP или HTTPS (рекомендуется HTTPS) * **Динамическое формирование полезной нагрузки**: Формирует тела JSON-запросов, сочетая статические значения с динамическими атрибутами из любой точки потока с помощью `{{attribute_name}}` синтаксис * **Настройка пользовательских заголовков**: Поддерживает до 10 пользовательских HTTP-заголовков для аутентификации и специфических требований API * **Поддержка вложенных атрибутов**: Ссылается на сложные структуры атрибутов, включая вложенные объекты и массивы в полезной нагрузке JSON * **Независимое выполнение**: Срабатывает, не дожидаясь ответов и не блокируя поток, обеспечивая надежную работу независимо от доступности внешней системы ## Параметры конфигурации {% columns %} {% column valign="middle" %} Узел Вебхук позволяет определить, как поток будет взаимодействовать с внешними системами через HTTP API-запросы. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} Давайте посмотрим, какие элементы использует этот узел и что вы можете настроить при работе с ним. ### Шаги настройки {% stepper %} {% step %} #### Укажите имя узла Введите описательное имя, которое определяет назначение вебхука. * Используйте имена, которые указывают на целевой сервис или действие (например, «Slack Контроль событий скорости» или «Создание тикета в CRM»). * Это имя отображается на диаграмме потока для удобной идентификации {% endstep %} {% step %} #### ID узла (генерируется автоматически) Под полем «Имя» в диалоговом окне отображается **ID узла** (например, `вебхук_1a2b3c4d`). Это поле доступно только для чтения — его нельзя редактировать или задавать значение. * ID генерируется автоматически при создании узла и остается неизменным на протяжении всего срока его существования * Используйте это, чтобы отличать результаты этого узла от результатов других узлов Вебхук в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md), где он отображается как атрибут, показывающий `0` (не сработал) или `1` (сработал) {% endstep %} {% step %} #### Настройте URL конечной точки Введите полный URL, по которому отправляются POST-запросы. * Укажите протокол: `http://` или `https://` (HTTPS настоятельно рекомендуется) * Убедитесь, что URL указывает на действительную конечную точку API, которая принимает POST-запросы * Пример: `https://api.example.com/v1/webhooks/device-alerts` {% endstep %} {% step %} #### Определите HTTP-заголовки Добавьте все заголовки, требуемые целевым API. 1. Нажмите **Добавить заголовок** для создания пар «ключ-значение» заголовков\ Все заголовки настраиваются пользователем, включая Content-Type. К распространённым заголовкам относятся: * `Content-Type: application/json` (требуется для JSON-данных) * `Авторизация: Bearer ` (для аутентификации API) * Пользовательские Управление API ключами или заголовки аутентификации в соответствии с требованиями сервиса 2. Нажмите значок удаления, чтобы удалить отдельные заголовки {% hint style="info" %} Поддерживается максимум 10 заголовков {% endhint %} {% endstep %} {% step %} #### Соберите тело запроса Переключитесь на **Тело** вкладку и определите структуру JSON, которая отправляется в конечную точку: * Введите корректный синтаксис JSON в поле Body * Используйте `{{attribute_name}}` чтобы ссылаться на любой атрибут из подключенных узлов * Поддерживает вложенные структуры JSON и массивы * Ссылки на атрибуты работают с вложенными путями (например, `{{location.latitude}}`) * Если ссылка на атрибут равна null или не существует, значение `null` отправляется в JSON **Пример тела Вебхука с динамическими атрибутами:** ```json { "alert_type": "speed_violation", "device_id": "{{device_id}}", "current_speed": "{{speed_mph}}", "threshold_exceeded": 80, "location": { "lat": "{{latitude}}", "lng": "{{longitude}}" }, "timestamp": "{{message_time}}", "водитель": "{{hardware_key}}" } ``` {% endstep %} {% step %} #### Сохраните конфигурацию Нажмите **Примените изменения** чтобы сохранить настройки узла Вебхука. {% endstep %} {% endstepper %} ## Поведение выполнения Вебхука Вебхук выполняется, не ожидая ответов от внешней конечной точки. Успех или неудача запроса Вебхука не влияет на дальнейшую работу потока и не блокирует обработку данных другими узлами. {% hint style="danger" %} В настоящее время выполнение Вебхука не включает автоматические повторы, ведение журнала неудачных попыток или обработку ответов. Если конечная точка возвращает ошибку или истекает время ожидания, Вебхук будет срабатывать снова при следующем входящем сообщении. В будущих обновлениях могут появиться ограничения скорости, задаваемые конечной точкой, и постановка запросов в очередь. {% endhint %} ### Вебхук и непрерывная потоковая передача данных **Узел Вебхук** принципиально отличается от **Узел передачи данных** по назначению и схеме выполнения: | Узел Вебхук | Узел передачи данных | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Выполняет отдельные вызовы API для каждого сообщения, отправляя настраиваемые полезные нагрузки, которые вы определяете. Идеально подходит для запуска внешних действий, отправки уведомлений или передачи выборочных данных в REST API. | Поддерживает непрерывные потоки данных через MQTT, передавая полные данные устройства в формате Navixy Generic Protocol. Предназначен для непрерывного сбора телеметрии и мониторинга в реальном времени. | Выбирайте вебхуки, когда нужно запускать внешние автоматизации или отправлять в конечные точки API только определенные атрибуты. Используйте выходные конечные точки для непрерывных потоков данных в аналитические платформы или системы мониторинга. Оба варианта могут сосуществовать в одном потоке. ### Интеграция с внешними системами Вебхук-узлы отлично подходят для запуска событийно-ориентированных действий в системах, предоставляющих REST API. К распространенным схемам интеграции относятся: * **Платформы обмена сообщениями**: Отправляйте уведомления в Slack, Microsoft Teams, WhatsApp или Telegram, когда условия устройства соответствуют определенным критериям * **ERP-системы**: Синхронизируйте данные устройства с платформами планирования ресурсов предприятия, чтобы обновлять уровни запасов, запускать процессы закупок или фиксировать использование оборудования для планирования техобслуживания * **Системы управления заявками**: Автоматически создавайте тикеты в службу поддержки или заявки на обслуживание в CRM-платформах при обнаружении проблем с устройством * **Сервисы оповещения**: Запускайте SMS-, email- или push-уведомления через сервисы вроде Twilio, SendGrid или Firebase, когда превышены пороговые значения * **Бизнес-автоматизация**: Инициируйте рабочие процессы в таких инструментах, как Zapier, Make (Integromat) или n8n, на основе телеметрии устройства * **Телематические системы**: Запускайте определённые действия или автоматизации в сторонних телематических решениях на основе обработанных данных, обеспечивая сценарии, управляемые событиями, такие как перерасчёт маршрута, уведомления водителя или обновления статуса во внешних системах управления транспортом * **Пользовательские приложения**: Активируйте собственную бизнес-логику, отправляя события устройства во внутренние API ## Часто задаваемые вопросы #### Как запускать вебхуки только при определённых условиях? Используйте заголовок **IF/THEN Логика** Узел для реализации условной логики перед Вебхуком. Этот **IF/THEN Логика** узел может оценивать атрибуты устройства и направлять данные в Вебхук только при выполнении условий. Подробнее см. [IF/THEN Логика](/docs/user/ru/guide/account/iot-logic/nodes/logic-node.md). #### Можно ли использовать несколько узлов Вебхука в одном потоке? Да. Добавьте несколько **узлов Вебхука** с разными конфигурациями, чтобы запускать различные внешние системы на основе одних и тех же данных устройства. Каждый Вебхук срабатывает независимо при получении данных. #### Что произойдет, если запрос Вебхука завершится ошибкой? Вебхук срабатывает, не дожидаясь ответа, и не повторяет попытку автоматически. Если внешняя конечная точка недоступна или возвращает ошибку, поток продолжает обработку в обычном режиме. Вебхук пытается сработать снова, когда поступает следующее сообщение. В настоящее время журналирование неудачных попыток Вебхука отсутствует. #### Как выполнить аутентификацию во внешних API? Настройте аутентификацию полностью через пользовательские заголовки. Распространенные подходы: * **Bearer-токены**: Добавьте заголовок `Authorization` со значением `Bearer your_token_here` * **Управление API ключами**: Добавьте пользовательские заголовки, как указано вашим поставщиком API * **Базовая аутентификация**: Добавьте заголовок `Authorization` со значением `Basic base64_encoded_credentials` Всегда включайте `Content-Type: application/json` в качестве заголовка при отправке JSON-нагрузок. #### Могу ли я ссылаться на атрибуты из нескольких связанных узлов? Да. Узел Вебхука может получать доступ к атрибутам из любого узла, подключенного к нему, включая параллельные ветви. Если несколько узлов отправляют данные в Вебхук, он срабатывает один раз для каждого входящего сообщения и может ссылаться на атрибуты из исходного пути этого сообщения. #### Какие данные я могу включить в тело Вебхука? Вы можете включить любую комбинацию из: * Статические значения, определенные напрямую в вашей JSON-конфигурации * Динамические атрибуты из потока с помощью `{{attribute_name}}` синтаксис * Вложенные атрибуты из сложных структур данных * Атрибуты, вычисленные в **узлах Вычисление атрибута** или обработанные через **IF/THEN Логика** узлы Тело должно быть корректным JSON. Если указанного атрибута не существует или он содержит значение null, `null` отправляется в JSON. #### Как я могу протестировать конфигурацию вебхука? Открыть [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md) для потока и выберите запускающее устройство. Найдите атрибут, соответствующий ID этого Узла: его значение переключится на `1` каждый раз, когда срабатывает вебхук, `0` иначе. Это подтверждает, что Вебхук сработал без необходимости доступа к конечной точке назначения. Чтобы проверить, что назначение действительно получило ожидаемую полезную нагрузку, рассмотрите возможность использования сервисов для тестирования Вебхук, например webhook.site или RequestBin, во время разработки, чтобы изучить точные запросы, которые отправляются. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/webhook-node.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.