> 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 Speed Контроль событий» или «Создание заявки в 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 %}
### Вебхук vs непрерывная потоковая передача данных
**Узел Вебхук** принципиально отличается от **Узел передачи данных** по назначению и схеме выполнения:
| Узел Вебхук | Узел передачи данных |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Выполняет отдельные вызовы 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).
#### Можно ли использовать несколько узлов Вебхука в одном потоке?
Да. Добавьте несколько **узлов Вебхука** с разными конфигурациями, чтобы запускать различные внешние системы на основе одних и тех же данных устройства. Каждый Вебхук срабатывает независимо, когда получает данные.
#### Что произойдет, если запрос Вебхука завершится ошибкой?
Вебхук срабатывает, не дожидаясь ответа, и не выполняет повторную попытку автоматически. Если внешний endpoint недоступен или возвращает ошибку, поток продолжает обработку в обычном режиме. Вебхук попытается сработать снова, когда поступит следующее сообщение. В настоящее время ведение журнала неудачных попыток срабатывания Вебхука отсутствует.
#### Как аутентифицироваться во внешних API?
Настройте аутентификацию полностью через пользовательские заголовки. Распространенные подходы:
* **Bearer-токены**: Добавьте заголовок `Authorization` со значением `Bearer ваш_токен_здесь`
* **Управление API ключами**: Добавьте пользовательские заголовки, как указано вашим провайдером API
* **Basic-аутентификация**: Добавьте заголовок `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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
