Уведомления из n8n через HTTP Request
В n8n уведомление в Депешер можно отправить узлом HTTP Request после нужного действия. Например, AI Agent подготовил результат, а следующий узел передал его в Telegram, Email, Пачку или в Depesher Desktop через входящий канал Депешера.
Подготовьте Депешер
Сначала создайте и подтвердите исходящий канал: Email, Telegram, группу Telegram, Пачку или Depesher Desktop. Затем создайте входящий канал для этого инструмента, свяжите его с выбранным получателем и скопируйте публичный URL. Выполните проверку из статьи «Первое уведомление».
Добавьте HTTP Request
Соедините выход нужного узла с HTTP Request. Для результата агента схема выглядит так:
text
AI Agent → HTTP RequestНастройте HTTP Request:
| Поле | Значение |
|---|---|
| Method | POST |
| URL | Публичный адрес вашего входящего канала Депешера |
| Send Body | Включено |
| Body Content Type | Raw |
| Content Type | text/plain |
| Body | Для первого теста: Проверка уведомления из n8n |
Режим Raw отправляет указанный текст как тело запроса. Описание полей есть в документации HTTP Request.
Если входящий канал защищён токеном, передайте заголовок Authorization со значением Bearer ВАШ_ТОКЕН через настройки авторизации или заголовков узла. Для хранения рабочего токена используйте credentials n8n.
Подставьте результат агента
Посмотрите фактический выход AI Agent. Если текст находится в поле output, переключите Body в режим Expression и вставьте:
text
{{ $json.output || "n8n AI Agent завершил работу" }}Если поле у вашего узла называется иначе, выберите его из выходных данных. Не полагайтесь на имя output, не проверив структуру результата. Для JSON-событий можно отправлять application/json и оформить уведомление шаблоном Депешера.
Проверьте выполнение
Запустите workflow вручную и посмотрите вход и выход HTTP Request. Затем проверьте историю канала и чат или почту получателя. Если узел получает несколько элементов данных, проверьте число выполненных отправок: одно выполнение workflow не обязательно означает одно уведомление.
Как уведомлять об ошибках
HTTP Request после AI Agent покрывает ветку, дошедшую до этого узла. Для сбоев основного workflow создайте отдельный error workflow с Error Trigger и HTTP Request. Настройка описана в документации обработки ошибок n8n.
Передавайте название workflow, этап и ссылку на запуск, если они есть в событии ошибки. Сохраните error workflow и выберите его в поле Error workflow в настройках основного workflow. Error Trigger срабатывает при ошибке автоматического запуска; ручной запуск основного workflow не проверяет эту связку. Проблемы с приёмом и получателями разбираются в диагностике доставки.
Разделите состояния и получателей через JSON
Для ошибок, завершения и запроса решения настройте один канал по рецепту состояний AI и workflow. Состояния задаёт ваша ветка workflow; они не извлекаются автоматически из ответа AI Agent.
В HTTP Request после успешного этапа оставьте POST, включите Send Body, выберите Body Content Type → JSON, Specify Body → Using Fields Below. Добавьте поля:
| Name | Value |
|---|---|
source | Обычный текст n8n |
status | Обычный текст completed |
run_id | Expression: {{ $execution.id }} |
message | Expression: {{ typeof $json.output === 'string' && $json.output.trim() ? $json.output : 'Этап workflow завершён; результат смотрите в n8n' }} |
Узел сериализует JSON, включая кавычки и переносы в output. Не склеивайте JSON из строк. Если результат хранится в другом поле, измените выражение после просмотра фактических данных.
В отдельном error workflow настройте HTTP Request после Error Trigger таким же образом:
| Name | Value |
|---|---|
source | Обычный текст n8n |
status | Обычный текст failed |
run_id | Expression: {{ $json.execution?.id ?? $execution.id }} |
message | Expression: {{ 'Ошибка workflow: ' + ($json.workflow?.name ?? 'название недоступно') }} |
При ошибке самого запускающего узла в событии может отсутствовать execution. Запасное значение — ID запуска error workflow, а не ID несуществующего основного выполнения. Такое различие описано в Error Trigger. Не назначайте этот error workflow самому себе; сбой его HTTP Request проверяйте по журналу n8n.
Если workflow имеет отдельную ветку запроса решения человека, поставьте HTTP Request перед ожиданием. Укажите status = waiting_for_input, тот же ID запуска и понятный message, например «Нужно проверить отчёт перед публикацией». Сам возврат AI Agent или наличие произвольного текста «жду» не подтверждает такую паузу.
В Options → Response включите Include Response Headers and Status, чтобы увидеть statusCode: 202. Оставьте Never Error выключенным: отказ HTTP должен быть заметен в выполнении. Параметры подтверждены справочником HTTP Request.
Проверьте успешную ветку вручную. Для Error Trigger используйте отдельный автоматический тестовый запуск основного workflow с контролируемой ошибкой. Для ожидания запустите свою ветку запроса решения. Для каждого события сверяйте JSON на входе HTTP Request, HTTP-ответ и результат в истории Депешера с таблицей общего рецепта. Ответ 202 сам по себе не подтверждает внешнюю доставку.