--- title: "HTTP Request node в n8n: REST API и auth — Nodbot" source_url: "https://nodbot.ru/nodes/http-request/" canonical_url: "https://nodbot.ru/nodes/http-request/" language: "ru" content_type: "KnowledgePage" section: "nodes" generated_at: "2026-05-30" word_count_source: 1063 --- # HTTP Request node в n8n: REST API и auth надёжные запросы ## AI summary HTTP Request node в n8n: авторизация, retries, pagination, rate limits, обработка ошибок API и проверка response schema. ## Best used for Страница объясняет «HTTP Request node в n8n: REST API и auth — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Из чего состоит API-запрос - Авторизация: не храните токены в тексте workflow - Как отправлять JSON без битых полей - Pagination: как не забрать только первую страницу - Retry, 429 и временные ошибки - Файлы и binary response - Как отлаживать HTTP Request - Где чаще всего нужен HTTP Request в российском стеке ## Source outline # HTTP Request node в n8n: REST API и auth надёжные запросы Обновлено: 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-запрос - Часть запроса | Где в ноде | Пример - HTTP method | Method | GET для чтения, POST для создания, PATCH для изменения - Endpoint | URL | https://api.example.ru/v1/leads - Query | Query Parameters | page=2 , limit=100 - Headers | Headers | Authorization , Content-Type , request id - Body | Body | JSON с полями лида, заказа или события - Response | Output | result , data , items , binary file ## Авторизация: не храните токены в тексте 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 - Сначала выполните тот же запрос через curl/Postman с теми же headers и body. - Сравните URL, method, Content-Type и Authorization. - В execution откройте вход в ноду и проверьте, не пришёл ли пустой phone/email/id. - Временно включите возврат полного ответа, включая status code и headers. - Для внешних 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 ждёт объект. ## Production-чеклист для HTTP Request node Используйте этот блок как быстрый контроль перед публикацией workflow или изменением существующей автоматизации. Он не заменяет staging, но помогает поймать самые частые отказы заранее. - Перед запуском: задать auth, timeout, retries, pagination и обработку не-2xx ответов. - Минимальный тест: выполнить запрос к тестовому endpoint и проверить schema response. - Типовой отказ: API возвращает 429/500, а workflow продолжает работу с неполными данными. - Что логировать: входной payload без секретов, статус внешнего API, branch ошибки, execution id и владельца процесса. Критерий готовности: сценарий проходит успешный путь, ошибочный путь и повтор события без дублей, потери данных и неконтролируемого падения execution. ## Проверка ноды на реальных items Ноду или паттерн «HTTP Request node в n8n» лучше проверять не на одном item, а на наборе входов: пустой объект, массив из нескольких items, неожиданный тип поля и повтор события. Так вы увидите, где ломается mapping ещё до подключения реального API. Для этой страницы базовый источник данных: payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом. Если нода меняет внешнюю систему, добавьте dry-run или review-ветку. - Слой | Что зафиксировать | Зачем - Вход | payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «HTTP Request node в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "event_id": "evt_...", "event_type": "object.updated", "received_at": "2026-05-29T10:00:00Z", "signature_valid": true, "dedupe_key": "provider:event_id", "payload_version": "v1" } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.