n8n webhook сценарий - это способ запустить workflow не по расписанию и не вручную, а сразу в момент события во внешней системе: пришёл заказ, оплата, заявка с Tilda-формы или сообщение из Telegram-бота на aiogram. За практику с n8n я собрал десятки таких связок - от простого приёма формы до интеграций с СДЭК и эквайрингом T‑Bank. Ниже - процесс так, как настраиваю его сам: с конкретными нодами, полями и ошибками, на которые обычно натыкаются в первый раз.
Что такое webhook-триггер в n8n и чем он лучше опроса по расписанию
Webhook-триггер - нода, которая создаёт в n8n собственный URL и слушает входящие HTTP-запросы. Как только внешний сервис отправляет на этот адрес POST или GET с данными, workflow запускается мгновенно, без задержки. Это принципиально отличается от Schedule Trigger, который опрашивает источник раз в 5, 15 или 60 минут и тратит ресурсы даже тогда, когда новых данных нет.
На практике разница ощутима. Если СДЭК меняет статус посылки, а вы опрашиваете их API по расписанию раз в час, клиент узнаёт о доставке с опозданием - и это плохо смотрится на фоне уведомлений, которые магазины на WooCommerce рассылают через встроенные вебхуки заказов практически в реальном времени. То же с оплатой через T‑Bank: банк присылает уведомление об успешном платеже webhook’ом сразу после списания, и если ловить его через нужный триггер, статус заказа в CRM обновляется за секунды, а не после следующего опроса.
Создаём ноду Webhook: пошаговая настройка
Добавляю в canvas ноду Webhook - она всегда открывающая для входящего сценария. У неё несколько ключевых полей, и от них зависит, заработает связка с первого раза или нет.
- HTTP Method - метод запроса, который будет присылать источник.
- Path - часть URL после /webhook/, обычно называю по смыслу события: order-received, cdek-status, payment-notify.
- Authentication - базовая защита на уровне ноды (разберу отдельно ниже).
- Respond - режим ответа внешнему сервису.
Метод запроса и путь
Большинство сервисов, с которыми приходится работать - T‑Bank, WooCommerce, СДЭК, кастомные формы на Tilda - отправляют POST с телом в JSON. GET оставляю для случаев, когда сервис умеет только дёргать URL с параметрами в query string, например простые пинги от мониторинга. Path делаю уникальным для каждого сценария: если на одном n8n крутится пять интеграций, пять разных путей избавляют от путаницы в логах и в Executions.
Respond Immediately или Respond to Webhook
По умолчанию нода отвечает сразу после срабатывания - Immediately, с кодом 200 и пустым телом. Этого достаточно для Tilda и большинства форм. Но T‑Bank и СДЭК в ряде сценариев ждут конкретный ответ (например, эхо переданного параметра или JSON нужной структуры) - тогда ставлю режим Respond to Webhook и добавляю отдельную ноду в конце цепочки, которая формирует тело ответа. Если этого не сделать, внешний сервис решит, что вебхук не обработан, и будет слать повторные попытки - иногда до десятка раз за несколько часов.
Проверяю ноду сразу после добавления - копирую Test URL и дёргаю его curl’ом, не дожидаясь, пока заработает реальный источник:
curl -X POST https://your-n8n-host/webhook-test/order-received
-H "Content-Type: application/json"
-d '{"order_id": 1234, "amount": 2500, "status": "paid"}'Так сразу видно, доходит ли запрос и что оказывается в $json на входе следующей ноды.
Тестовый и продакшн URL: в чём разница
У каждой Webhook-ноды два адреса. Test URL работает только пока workflow открыт в редакторе и нажата кнопка Listen for Test Event - он живёт одно срабатывание и годится исключительно для отладки. Production URL начинает принимать запросы только после активации workflow тумблером в правом верхнем углу.
Частая ошибка новичков - протестировать сценарий на Test URL, убедиться, что всё работает, и забыть подставить в настройках источника (личном кабинете T‑Bank, вебхуках WooCommerce, коллбэке Tilda) именно продакшн-адрес. В результате первые дни или недели реальные события никуда не приходят, а в логах n8n тишина, потому что запросы вообще не долетают до сервера.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Обрабатываем данные из webhook: примеры реальных сценариев
Данные из входящего запроса доступны сразу через $json - n8n парсит JSON-тело автоматически. Если нужен доступ к заголовкам или query-параметрам, беру $request.headers и $request.query. Дальше обычно ставлю ноду Edit Fields (Set), чтобы выбрать только нужные поля и переименовать их в понятные - order_id вместо OrderId, amount вместо Amount - это сильно упрощает жизнь на следующих шагах, особенно если данные потом попадают в Google Sheets или CRM.
Если через один webhook приходят события разных типов (например, T‑Bank шлёт и успешные платежи, и отмены), сразу после Webhook-ноды ставлю IF или Switch, который разводит поток по полю status или event_type.
| Источник события | Метод авторизации | Что обычно передаёт |
|---|---|---|
| Tilda (formsubmit) | без токена, проверка по домену источника | телефон, email, поля формы |
| T‑Bank (уведомление об оплате) | подпись Token, SHA-256 по параметрам | статус платежа, сумма, OrderId |
| WooCommerce (вебхук заказов) | секретный ключ в заголовке X‑WC-Webhook-Signature | данные заказа, товары, покупатель |
| СДЭК (statusnotify) | IP whitelist / ключ клиента | номер заказа, код статуса, дата |
| Telegram-бот (aiogram, форвард в n8n) | секретный path/token в URL | текст сообщения, chat_id, вложения |
Под каждый из этих сценариев у меня уже собраны рабочие шаблоны - часть выложена в библиотеке готовых сценариев для n8n, откуда можно взять структуру workflow и адаптировать под свои поля вместо сборки с нуля.
Защита webhook-сценария: авторизация и проверка подписи
URL вебхука - это, по сути, открытая дверь в workflow, и если её никак не защитить, рано или поздно кто-то начнёт слать туда мусорные запросы или пытаться подделать события (особенно опасно для платёжных уведомлений). В ноде Webhook есть встроенная Authentication: Basic Auth или Header Auth - задаёте логин/пароль или секретный заголовок, и без него n8n отвечает 403 ещё до запуска workflow.
Для T‑Bank и подобных сервисов этого мало - они присылают подпись (Token), которую нужно пересчитать на своей стороне и сравнить. Делаю это в ноде Code:
const crypto = require('crypto');
const params = $input.first().json;
const secret = 'ваш_секретный_ключ';
const sorted = Object.keys(params)
.filter(k => k !== 'Token')
.sort()
.map(k => params[k])
.join('');
const hash = crypto.createHash('sha256').update(sorted + secret).digest('hex');
if (hash !== params.Token) {
throw new Error('Подпись webhook не совпадает');
}
return $input.all();Для СДЭК обычно хватает связки IP-whitelist на уровне nginx перед n8n плюс секретный path в самом URL - так лишний трафик отсекается ещё до попадания в workflow.
Частые ошибки при настройке webhook-сценария в n8n
- Workflow не активирован - Production URL молчит, хотя Test URL при ручной проверке работал.
- Неправильный режим ответа - источник ждёт конкретное тело или код, а нода отвечает Immediately с пустым JSON, и после нескольких неудачных попыток сервис помечает вебхук как нерабочий и отключает его.
- Нет обработки повторных запросов - многие сервисы, включая T‑Bank, присылают уведомление несколько раз, если не получили быстрый 200; без проверки на дубликат по order_id заказ в CRM обновляется дважды.
- Нет логирования сырого payload - когда источник меняет формат данных (а такое бывает при обновлении API СДЭК или WooCommerce), без сохранённого тела запроса разбираться в падении workflow приходится вслепую.
- Секрет захардкожен прямо в ноде Code - при передаче проекта или смене ключа приходится искать его по всем нодам вместо одной переменной окружения.
Настройка одного простого webhook-приёма занимает у меня час-полтора. Комплексная интеграция - с проверкой подписи, разводкой по типам событий, записью в CRM и обработкой повторов - обычно неделя работы, и как услугу такую автоматизацию в n8n оцениваю от 25 000 ₽.
Связка сервисов без программистов
Автоматизация / n8n
от 25 000 ₽
Подробнее →Частые вопросы
Чем webhook в n8n отличается от Schedule Trigger?
Schedule Trigger опрашивает источник по расписанию и годится, когда события редкие или API не умеет присылать уведомления сам. Webhook запускает workflow сразу по факту события, без задержки и без лишних запросов к API, если данных ещё нет.
Можно ли обработать несколько типов событий через один webhook?
Да, если источник шлёт все события на один URL с разным содержимым - ставлю после Webhook-ноды IF или Switch и развожу поток по полю вроде event_type или status, как это устроено, например, у T‑Bank.
Нужен ли отдельный домен или сервер для webhook, если n8n развёрнут самостоятельно (self-hosted)?
Нужен публичный HTTPS-адрес, до которого дотянется внешний сервис - свой домен с SSL-сертификатом или туннель вроде ngrok для тестов. На локальном 127.0.0.1 без проброса ни T‑Bank, ни СДЭК, ни Tilda до вебхука не достучатся.
Что делать, если внешний сервис не получает ответ 200 от webhook и продолжает слать повторы?
Проверить режим ответа ноды - часто причина в том, что тяжёлая обработка идёт до ответа, и источник не дожидается таймаута. Переключаю на Respond Immediately сразу на входе, а тяжёлую логику увожу в отдельную ветку после ответа, либо явно формирую нужное тело через Respond to Webhook, если источник проверяет содержимое.