HTTP Request node в n8n: REST API, авторизация и надёжные запросы ¶

Обновлено: 2026-05-29

HTTP Request node — универсальная нода для API, которых нет среди готовых интеграций n8n. Через неё вызывают REST endpoint, отправляют JSON, получают файлы, работают с Bearer token, Basic Auth, OAuth2, query-параметрами, headers, pagination и retry.

Эту ноду стоит держать простой: она должна делать один внешний вызов. Подготовку payload лучше вынести в Set/Edit Fields или Code node, а обработку ответа — в отдельный шаг. Тогда execution history читается быстрее, а ошибки API не превращаются в “чёрный ящик”.

Из чего состоит API-запрос

Авторизация: не храните токены в тексте workflow

Для API-ключей используйте credential или переменную окружения. Если вставить токен прямо в header, он может попасть в экспорт workflow, скриншот или лог. Для Bearer token header обычно выглядит так:

Authorization: Bearer {{$credentials.apiToken}}

Для российских сервисов часто встречаются два варианта: входящий webhook URL с секретом в path и полноценный OAuth2. Первый проще для внутренней интеграции одного аккаунта, второй нужен для продукта, который подключают разные клиенты.

Как отправлять JSON без битых полей

Перед HTTP Request соберите payload в отдельной ноде. Не отправляйте весь исходный webhook целиком: во внешнее API должны уходить только нужные поля. Пример нормализованного лида:

{
  "external_id": "{{$json.event_id}}",
  "name": "{{$json.name}}",
  "phone": "{{$json.phone_e164}}",
  "email": "{{$json.email}}",
  "source": "tilda",
  "utm_source": "{{$json.utm_source}}"
}

Если API возвращает 400 или 422, сначала сравните реальный JSON из execution с документацией метода. Чаще всего проблема не в n8n, а в типе поля, обязательном ID, пустой строке или неверном Content-Type.

Pagination: как не забрать только первую страницу

Многие API возвращают данные частями. Если workflow забирает контакты, сделки, товары или заказы, проверьте, есть ли в ответе next, page, offset, cursor или has_more. Без pagination сценарий выглядит рабочим, но silently обрабатывает только первый набор данных.

• page/limit: увеличивайте page, пока ответ не станет пустым.
• offset/limit: прибавляйте limit к offset.
• cursor: сохраняйте cursor из ответа и передавайте его в следующий запрос.
• date window: для больших данных разбивайте запросы по датам.

Retry, 429 и временные ошибки

Для 429 Too Many Requests не надо просто увеличивать число попыток. Сначала уменьшите частоту запросов, добавьте Wait между пачками и учитывайте лимиты API. В настройках ноды можно включить Retry on Fail, но задержка должна быть осмысленной: если сервис разрешает один запрос в секунду, пауза в 100 мс только усугубит проблему.

Для 5xx уместны повторные попытки и dead-letter ветка. Для 401 retry обычно бесполезен: сначала обновите токен. Для 403 проверяйте права credential, тариф, scopes и доступ пользователя.

Файлы и binary response

Если API отдаёт PDF, картинку или архив, включайте получение binary data и сразу задавайте понятное имя файла. Для последующей загрузки в Google Drive, Яндекс Диск, CRM или почту полезно сохранять MIME type, размер и источник файла.

Как отлаживать HTTP Request

1. Сначала выполните тот же запрос через curl/Postman с теми же headers и body.
2. Сравните URL, method, Content-Type и Authorization.
3. В execution откройте вход в ноду и проверьте, не пришёл ли пустой phone/email/id.
4. Временно включите возврат полного ответа, включая status code и headers.
5. Для внешних API логируйте request_id или свой correlation_id.

Где чаще всего нужен HTTP Request в российском стеке

• Битрикс24: вызов REST методов через входящий webhook или OAuth.
• amoCRM: создание сделки, поиск контакта, обновление статуса.
• DaData: нормализация телефона, ФИО, адреса и организации.
• ЮKassa: проверка статуса платежа и обработка уведомления.
• 1С: обмен через HTTP endpoint или промежуточный API.

Готовый каркас

Для надёжного API-вызова используйте связку HTTP Request retry + DLQ: она показывает, как отделить временные ошибки от постоянных, куда складывать неуспешные события и как не терять payload.

Официальные источники

• HTTP Request node
• Common issues
• Handling API rate limits

FAQ

Почему HTTP Request возвращает 401?

Чаще всего токен истёк, header Authorization собран неверно или credential не имеет нужных scopes. Повторять такой запрос без обновления токена бессмысленно.

Что делать с 429?

Добавить паузу, уменьшить параллельность, обрабатывать данные пачками и учитывать лимиты API. Retry помогает только вместе с правильной задержкой.

Почему API не принимает body?

Проверьте Content-Type, режим body, обязательные поля и типы данных. Частая ошибка — отправлять строку вместо числа, пустой ID или массив там, где API ждёт объект.