Webhook и API-интеграция в n8n: руководство по HTTP-ноду

n8n webhook API Нода Webhook Trigger в n8n преобразует входящие HTTP-запросы в выполнение рабочих процессов, тогда как HTTP Request нода вызывает любой REST API изнутри рабочего процесса. Вместе эти две ноды предоставляют наиболее гибкий способ интеграции сервисов, не имеющих нативного коннектора n8n.

Webhook и HTTP-нод в n8n: разница между триггером и запросом

Нода Webhook Trigger — это URL, который n8n открывает для внешнего мира; входящие HTTP-запросы на этот URL запускают рабочий процесс. HTTP Request нода отправляет запросы из рабочего процесса во внешние сервисы. Один перехватывает входящий трафик, другой генерирует исходящие запросы.

Понимание различия между двумя HTTP-ориентированными нодами n8n является основой правильной архитектуры интеграции. Движок рабочих процессов n8n получает события через ноды-триггеры и обрабатывает их последовательными нодами. Webhook Trigger — наиболее гибкий из этих триггеров: n8n предоставляет уникальный URL, и любой HTTP-запрос на него — GET, POST, PUT, PATCH или DELETE — немедленно выполняет рабочий процесс.

HTTP Request нода выполняет иную роль. Во время выполнения рабочего процесса она отправляет запрос к любому указанному внешнему API и передаёт ответ следующим нодам. Вы можете использовать её для подключения к вашей CRM, ERP или любой SaaS-платформе. Каждый сервис, взаимодействующий по протоколу HTTP, можно включить в рабочий процесс через эту ноду — независимо от наличия нативного коннектора n8n.

Настройка Webhook Trigger: URL, HTTP-метод и аутентификация

После добавления ноды Webhook Trigger n8n предоставляет два URL: один для тестирования и один для продакшна. HTTP-метод, режим ответа и опциональная аутентификация настраиваются непосредственно в панели ноды.

При добавлении ноды Webhook Trigger n8n автоматически генерирует уникальный путь. Его можно настроить — например, присвоить понятное имя вроде `/webhook/registratsiya-klienta`. n8n отображает тестовый URL (`/webhook-test/...`) и продакшн URL (`/webhook/...`) раздельно. Тестовый URL активен только при ручном запуске рабочего процесса; продакшн URL активен всё время, пока рабочий процесс включён.

Оставить HTTP-метод как POST подходит для большинства сценариев, однако доступны также GET, PUT, PATCH или DELETE. Режим ответа является важным решением: 'Immediately' возвращает 200 OK сразу после получения запроса, пока рабочий процесс продолжается в фоне. 'When Last Node Finishes' ожидает завершения всего рабочего процесса и возвращает выходные данные последней ноды в качестве тела ответа — этот режим предпочтителен для синхронных сценариев API-шлюза.

• Path: необязательный пользовательский URL-путь (например /webhook/orders)
• HTTP Method: GET, POST, PUT, PATCH, DELETE или ANY
• Response Mode: Immediately или When Last Node Finishes
• Response Data: Last Node или No Data
• Authentication: None, Basic Auth или Header Auth

При включённой аутентификации рабочий процесс запускают только запросы с корректными учётными данными; запросы без аутентификации отклоняются с кодом 401. Это защищает ваш webhook endpoint от несанкционированных вызовов и помогает соответствовать корпоративным требованиям безопасности. Подробнее о корпоративной конфигурации безопасности — в руководстве по безопасности и корпоративному управлению n8n.

Вызов любого API с помощью HTTP Request ноды

HTTP Request нода позволяет настраивать URL, HTTP-метод, заголовки, параметры запроса, тело запроса и аутентификацию в едином интерфейсе. Через эту ноду можно подключиться к любому внутреннему или внешнему REST API.

Панель конфигурации HTTP Request ноды представляет собой полноценный интерфейс HTTP-клиента. В поле Method можно выбрать GET, POST, PUT, PATCH, DELETE или HEAD. В поле URL можно ввести статический адрес или построить динамический URL с помощью выражений n8n из выходных данных предыдущих нод — например, `https://api.example.com/users/{{ $json.userId }}` получает профиль разного пользователя при каждом выполнении.

Заголовки, параметры запроса и тело запроса управляются в отдельных вкладках. Для отправки JSON-тела выберите 'JSON' в качестве типа тела и введите пары ключ-значение или напишите выражение JSON напрямую. Переключитесь в режим 'Form Data' для отправки данных формы. Режим 'Binary' доступен для загрузки файлов и других бинарных данных.

Включение опций 'Send Query Parameters' и 'Send Headers' открывает дополнительные поля. Поскольку они поддерживают выражения, вы можете напрямую использовать динамические значения из предыдущих нод. Например, можно итерировать по списку записей, полученных из запроса к базе данных, и делать отдельный API-вызов для каждой записи — управляя пропускной способностью с помощью ноды SplitInBatches n8n.

Аутентификация и учётные данные: API-ключ, OAuth2, Header Auth

n8n хранит учётные данные в зашифрованном виде и позволяет повторно использовать объекты Credential в нескольких рабочих процессах. Поддерживаемые типы: API-ключ, Header Auth, Basic Auth и OAuth2 (потоки Authorization Code и Client Credentials).

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

Поддержка OAuth2 — одна из наиболее мощных функций n8n. В потоке Authorization Code n8n управляет перенаправлением авторизации через браузер; при истечении срока действия access token n8n автоматически использует refresh token для получения нового в фоновом режиме. Это позволяет интегрировать в рабочие процессы корпоративные сервисы на базе OAuth2 — такие как Google Workspace, Microsoft 365 или Salesforce — без ручного управления токенами. Для соответствия корпоративным политикам безопасности рекомендуем изучить руководство по безопасности и управлению n8n.

При создании Credential кнопка 'Test Credential' проверяет его корректность перед сохранением. Эта функция позволяет выявить неправильные конфигурации на ранних этапах и предотвращает потерю времени при тестировании рабочих процессов.

Трансформация данных: JSON, выражения и Code нода

Для преобразования ответов API в данные рабочего процесса используйте выражения n8n (синтаксис двойных фигурных скобок) или Code ноду (JavaScript или Python). Выражения справляются с простым сопоставлением полей; Code нода берёт на себя сложную логику трансформации.

JSON-ответ, возвращаемый HTTP Request нодой, автоматически передаётся следующим нодам. Движок выражений n8n позволяет обращаться к глубоко вложенным структурам JSON с помощью точечной нотации и индексации массивов — например, `{{ $json.data.items[0].name }}`. Вы читаете из выхода текущей ноды через `$json`, обращаетесь ко всем элементам через `$items()` и используете переменные рабочего процесса через `$vars`.

Для сложных трансформаций данных предпочтительна Code нода (ранее Function нода). Она предоставляет полноценную среду выполнения JavaScript или Python: фильтруйте массивы, преобразовывайте объекты, конвертируйте форматы дат или объединяйте данные из нескольких источников. Code нода — мощная альтернатива в каждой ситуации, когда стандартного движка выражений n8n недостаточно.

• {{ $json.fieldName }} — чтение поля из текущего элемента
• {{ $json.nested.object.value }} — доступ к вложенному JSON
• {{ $items('NodeName')[0].json.field }} — получение выхода конкретной ноды
• {{ $now.format('YYYY-MM-DD') }} — выражения для даты/времени
• Code нода: return items.map(item => ({ json: { id: item.json.id, name: item.json.name } })) — трансформация элементов

При работе с большими наборами данных используйте SplitInBatches для обработки данных порциями; выполняйте HTTP-запрос на каждую порцию, чтобы оптимизировать использование памяти и соблюдать ограничения скорости API. Для интеллектуального сопоставления данных и ИИ-трансформаций смотрите руководство по настройке ИИ-агента в n8n.

Обработка ошибок и повторные попытки: Retry On Fail и Error Workflow

Опция 'Retry On Fail' в HTTP Request ноде автоматически повторяет запрос при временных сетевых ошибках или ответах 5xx. Для критических рабочих процессов выделенный Error Workflow автоматизирует уведомления об ошибках и компенсирующие действия.

В продакшн-среде API-интеграции неизбежно сталкиваются с временными ошибками: таймауты сети, ограничение частоты запросов (429) или временные сбои сервера (503). n8n предоставляет опцию 'Retry On Fail' на уровне HTTP Request ноды. При включении задаётся максимальное количество попыток и время ожидания между ними (в миллисекундах). Экспоненциальный откат можно смоделировать, добавив ноду Wait между повторными попытками.

Помимо обработки ошибок на уровне ноды, n8n предлагает управление ошибками на уровне рабочего процесса. Для каждого рабочего процесса можно определить 'Error Workflow'; при возникновении необработанной ошибки в основном рабочем процессе этот выделенный рабочий процесс запускается автоматически. Error Workflow получает сообщение об ошибке и контекст через `$execution.error`, что позволяет автоматизировать компенсирующие действия: отправку уведомления в Slack, запись неудавшейся записи в базу данных или email-оповещение администратора.

1. HTTP Request нода > Settings > Retry On Fail: Включено
2. Max Tries: 3–5 (5 для критических интеграций)
3. Wait Between Tries: 1000–5000 мс (в зависимости от rate limit API)
4. Settings > On Error: оцените 'Continue' vs. 'Stop And Error'
5. Уровень рабочего процесса: Settings > Error Workflow — подключите обработчик ошибок
6. Внутри Error Workflow: нода уведомлений (Slack, email) + нода логирования (база данных или лог-файл)

Управление rate limit особенно критично при массовых операциях. Превышение допустимого числа запросов в секунду или минуту приводит к ошибке 429. Для предотвращения этого ограничьте размер пакета с помощью SplitInBatches и добавьте Wait ноду между пакетами, чтобы сценарии обработки больших объёмов данных выполнялись безопасно в рамках ограничений API.

Практический пример: пошаговая интеграция собственного API

Для интеграции собственного или закрытого API с n8n: получите данные с помощью Webhook Trigger, вызовите API через HTTP Request ноду, преобразуйте ответ с помощью Code ноды и добавьте обработку ошибок. Этот шаблон применим к любому сервису без нативного коннектора.

Рассмотрим реальный сценарий: внутренняя ERP-система вызывает webhook n8n при создании нового заказа. Рабочий процесс перехватывает это событие, передаёт детали заказа во внешний API логистики, получает номер отслеживания из ответа и отправляет его в систему уведомлений клиентов. Ни один из этих трёх сервисов не имеет нативного коннектора n8n — однако все они взаимодействуют через HTTP.

1. Webhook Trigger: получает POST-запрос от ERP (JSON заказа). Path: /webhook/novyy-zakaz. Аутентификация: Header Auth (X-ERP-Secret).
2. HTTP Request (API логистики): POST https://api.logistics.example.com/v1/shipments. Тело: JSON из данных заказа ERP. Auth: API-ключ (Header: Authorization: Bearer {{credential}}). Retry On Fail: Вкл., Max 3.
3. Code нода: извлекает tracking_number и estimated_delivery из ответа API логистики; формирует payload уведомления вместе с email-адресом клиента.
4. HTTP Request (API уведомлений): POST https://api.notification.example.com/send. Тело: payload из Code ноды. Auth: Basic Auth.
5. Error Workflow: при ошибке на любом шаге отправляется уведомление в Slack, а ID неудавшегося заказа записывается в базу данных.

Этот шаблон охватывает подавляющее большинство корпоративных сценариев автоматизации. Для более сложных случаев — многоэтапная авторизация OAuth2, асинхронные API, гибридные архитектуры с webhook и опросом — обратитесь к руководству по корпоративным сценариям использования n8n. Если вы хотите добавить ИИ-возможности к своим интеграциям, руководство по настройке ИИ-агента в n8n предлагает исчерпывающую отправную точку.

Гибкость n8n позволяет включить в рабочий процесс любую систему, взаимодействующую через HTTP — облачные SaaS-решения, корпоративные legacy-системы или IoT-устройства. Зашифрованное управление учётными данными, ролевой контроль доступа и журналы аудита обеспечивают соответствие корпоративным требованиям безопасности.

Часто задаваемые вопросы

Что такое webhook и как он работает в n8n?

Webhook — это механизм, при котором одно приложение отправляет HTTP-запрос на другой URL при наступлении определённого события. В n8n нода Webhook Trigger предоставляет URL, который ожидает такие запросы; каждый входящий запрос автоматически запускает рабочий процесс.

Что делает HTTP Request нода и с какими API она совместима?

HTTP Request нода отправляет запрос из рабочего процесса n8n на любой HTTP/HTTPS-endpoint. Она совместима с любым сервисом, поддерживающим стандарт REST API, и является основным методом интеграции для собственных, корпоративных или закрытых API без нативного коннектора n8n.

Как осуществляется аутентификация API в n8n?

В менеджере Credentials создаётся объект Credential с выбором одного из поддерживаемых типов: API-ключ, Header Auth, Basic Auth или OAuth2. Этот Credential выбирается в HTTP Request ноде и автоматически применяется ко всем запросам; учётные данные хранятся в зашифрованном виде.

Поддерживает ли n8n OAuth2? Автоматически ли обновляется токен?

Да, n8n поддерживает OAuth2 Authorization Code и Client Credentials. При истечении срока действия access token n8n автоматически использует refresh token для получения нового в фоне; рабочий процесс продолжается без перебоев и без ручного вмешательства.

Как управлять ограничениями скорости API (rate limit) в n8n?

Используйте SplitInBatches для разбивки массовых запросов на порции и добавляйте Wait ноду между пакетами, чтобы соблюдать допустимую скорость API. Опция Retry On Fail в HTTP Request ноде автоматически повторяет запрос при ошибках 429.

Как работает обработка ошибок для HTTP Request ноды в n8n?

Retry On Fail можно включить на уровне ноды. На уровне рабочего процесса определите Error Workflow для обработки необработанных ошибок — отправки уведомлений в Slack, записи неудавшихся записей в базу данных или автоматического запуска компенсирующих действий.

Можно ли интегрировать внутренний или закрытый API с n8n?

Да. HTTP Request нода работает с любым API, доступным по URL. В самостоятельно развёрнутом n8n, установленном на сервере с доступом к внутренней сети, можно также подключаться к частным API за VPN или межсетевым экраном.

Можно ли использовать Webhook и HTTP Request ноды в одном рабочем процессе?

Да, это распространённый шаблон. Webhook Trigger получает данные снаружи, а одна или несколько HTTP Request нод в рабочем процессе отправляют запросы к разным API. Это позволяет оркестрировать многосистемные интеграции в едином рабочем процессе.

Заключение

Вместе Webhook Trigger и HTTP Request ноды n8n позволяют включить в рабочий процесс любой сервис на базе HTTP. Для собственных, корпоративных или закрытых API без нативных коннекторов эти две ноды обеспечивают гибкую и безопасную основу интеграции. Зашифрованное управление учётными данными, поддержка OAuth2 и автоматическое обновление токенов отвечают корпоративным требованиям безопасности и повышают производительность разработчиков.

Логика повторных попыток, обработка ошибок и Error Workflow делают ваши интеграции готовыми к продакшн-среде. Для получения сценариев интеграции, специфичных для вашей отрасли, и настройки инфраструктуры n8n в корпоративном масштабе свяжитесь с командой интеграции Sora для бесплатной ознакомительной консультации.