Триггеры и вебхуки в n8n: как запускается воркфлоу

Триггер - это ответ на вопрос «когда этот воркфлоу должен выполниться». Он всегда первый и всегда один: воркфлоу не может начинаться с двух точек входа.

Виды триггеров

Вебхук - n8n даёт публичный URL, и выполнение стартует, когда туда приходит запрос. Это основной способ реагировать на события снаружи: оплаты, формы, колбэки API.

Расписание - запуск по времени или cron-выражению. Для отчётов, синхронизаций и регулярных проверок.

Триггеры сервисов - готовые блоки под конкретные системы: новое письмо, новая строка в таблице, сообщение в чате. Под капотом это либо вебхук, либо периодический опрос - и разница важна: опрос узнаёт о событии не мгновенно, а на следующей проверке.

Ручной запуск - кнопка в редакторе. Для отладки, не для продакшена.

Тестовый и боевой URL - главная путаница

У ноды вебхука два разных адреса, и большая часть вопросов «почему не работает» растёт отсюда.

Тестовый живёт, только когда вы нажали в редакторе кнопку прослушивания. Он ждёт один запрос, показывает пришедшие данные и замолкает. Это инструмент отладки: удобно один раз посмотреть, что реально шлёт сервис.

Боевой работает постоянно, но только у активированного воркфлоу. Не активировали - адрес отвечает ошибкой.

Отсюда практическое следствие: интеграция, настроенная на тестовый URL, перестанет работать, как только вы закроете редактор. При переносе в прод нужно сменить адрес у вызывающей стороны, а не только включить тумблер.

Почему вебхук не приходит

Порядок проверки, который закрывает почти все случаи:

1. Воркфлоу активен? Самая частая причина.
2. Тот ли URL? Тестовый вместо боевого - вторая по частоте.
3. n8n знает свой публичный адрес? Если не задан WEBHOOK_URL, интерфейс покажет localhost - см. установку.
4. HTTPS есть? Многие сервисы не отправляют вебхуки на http.
5. Метод совпадает? Нода ждёт POST, а сервис шлёт GET - запрос не найдёт обработчик.
6. Прокси не режет? Слишком строгий таймаут или лимит размера тела на реверс-прокси обрывает запрос до n8n.

Если сомневаетесь, кто виноват - n8n или отправитель, - проверьте адрес обычным curl. Ответ снимает половину гипотез сразу.

Ответ вызывающей стороне

По умолчанию вебхук отвечает сразу, не дожидаясь конца воркфлоу. Это правильно в большинстве случаев: отправитель получил подтверждение и не висит.

Но иногда нужно вернуть результат работы - например, вы делаете API-эндпоинт. Тогда режим ответа переключается на возврат данных из указанной ноды, и здесь появляется ограничение, о котором стоит помнить: вызывающая сторона ждёт. Если воркфлоу выполняется полминуты, отправитель полминуты держит соединение - и его собственный таймаут может сработать раньше вашего ответа.

Рабочее правило: если обработка длинная, отвечайте сразу «принято», а результат отдавайте отдельно - колбэком, сообщением или записью в базу.

Расписание и таймзоны

Расписание задаётся интервалом или cron-выражением. Главная ловушка здесь не в синтаксисе, а в часовом поясе: по умолчанию n8n живёт в UTC, и «каждый день в 9:00» означает 9 утра по UTC, а не по-вашему. Задайте таймзону при установке - это одна переменная, которая избавляет от регулярного недоумения.

Вторая деталь: у частых расписаний выполнения могут накладываться. Если запуск раз в минуту, а работа длится две, вы получите параллельные копии, конкурирующие за одни данные. Либо ставьте интервал с запасом, либо делайте воркфлоу устойчивым к параллельному запуску.

Защита публичного эндпоинта

Вебхук - это открытый адрес в интернете. Его найдут: сканеры перебирают пути постоянно.

Минимальный набор мер:

• Секрет в запросе - заголовок или токен, который вы проверяете первой же нодой и обрываете выполнение, если он не совпал.
• Проверка подписи, если сервис её присылает. Так делают платёжные системы и GitHub - это надёжнее токена, потому что подтверждает и содержимое.
• Ничего не выполнять до проверки. Валидация должна стоять раньше любых действий с внешним миром.

И отдельно: не считайте, что «длинный случайный путь» - это защита. Он не секрет, он просто адрес; он утечёт в логи, в историю браузера и в настройки сервиса, который его вызывает.