--- title: "n8n HTTP Request — как подключить любой API - Nodbot" source_url: "https://nodbot.ru/code/http-request-api/" canonical_url: "https://nodbot.ru/code/http-request-api/" language: "ru" content_type: "KnowledgePage" section: "code" generated_at: "2026-05-30" word_count_source: 1640 --- # n8n HTTP Request — как подключить любой API ## AI summary Как подключать API через n8n HTTP Request: auth, headers, body, retries, pagination и диагностика ответов. ## Best used for Страница объясняет «n8n HTTP Request — как подключить любой API - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Что такое HTTP Request в n8n - Какие данные нужны для подключения API - Как настроить n8n HTTP Request пошагово - Как выбрать HTTP-метод - Как передать авторизацию в HTTP Request - Bearer token - API key - Как отправить JSON в теле запроса ## Source outline # n8n HTTP Request — как подключить любой API Обновлено: 2026-05-29 n8n HTTP Request — это нода для отправки HTTP-запросов к внешним API прямо из workflow. Она используется в n8n для получения данных, создания записей, отправки событий и интеграции сервисов без готовой ноды. В этой статье: как настроить HTTP Request, передать авторизацию, отправить JSON, обработать ответ и избежать частых ошибок. Короткий ответ Если у сервиса есть REST API, его почти всегда можно подключить к n8n через HTTP Request . Для этого нужны URL endpoint, HTTP-метод, параметры авторизации и формат тела запроса. ## Что такое HTTP Request в n8n HTTP Request в n8n — это универсальная нода для работы с REST API. Она отправляет запрос на указанный URL и возвращает ответ в виде данных workflow. Нода заменяет готовую интеграцию, когда нужного сервиса нет в списке n8n. Она также полезна, когда готовая нода не поддерживает конкретный endpoint API. Типовые задачи для HTTP Request: - получить данные из CRM, таблицы, базы знаний или внутреннего сервиса; - создать лид, сделку, заказ или задачу во внешней системе; - отправить webhook-событие в другой backend; - вызвать AI API, например OpenAI-compatible endpoint; - проверить статус операции по ID. ## Какие данные нужны для подключения API Для подключения API через HTTP Request нужны endpoint, метод, авторизация и схема данных. Эти параметры обычно описаны в документации сервиса. Минимальный набор: - Параметр | Где искать | Пример - URL | API reference | https://api.example.com/v1/tasks - Method | Описание endpoint | GET , POST , PATCH , DELETE - Authentication | Раздел Auth | Bearer token, API key, Basic Auth - Headers | Раздел Headers | Content-Type: application/json - Body | Раздел Request body | JSON с полями объекта - Response | Раздел Response | JSON, который вернёт API Термин Endpoint — это конкретный URL API для одной операции. Например, /v1/users может возвращать список пользователей, а /v1/users/123 — одного пользователя. ## Как настроить n8n HTTP Request пошагово Настройка n8n HTTP Request начинается с выбора метода и URL. После этого добавляют авторизацию, параметры запроса и тело. - Открой workflow в n8n. - Нажми + на холсте. - Найди ноду HTTP Request . - В поле Method выбери HTTP-метод. - В поле URL вставь endpoint API. - В блоке Authentication выбери способ авторизации. - Включи Send Headers , если API требует заголовки. - Включи Send Body , если запрос отправляет данные. - Нажми Test step и проверь ответ. Пример простого GET-запроса: ``` { "method" : "GET" , "url" : "https://www.cbr-xml-daily.ru/daily_json.js" } ``` После выполнения n8n сохранит ответ API в $json . Эти данные можно передать в следующую ноду. ## Как выбрать HTTP-метод HTTP-метод определяет действие, которое API выполнит с ресурсом. Метод нужно брать из документации endpoint. - Метод | Что делает | Когда использовать - GET | Получает данные | список заказов, карточка клиента, статус задачи - POST | Создаёт объект или запускает действие | новый лид, новая заявка, запуск генерации - PUT | Полностью заменяет объект | полное обновление профиля - PATCH | Частично обновляет объект | изменить статус, поле или тег - DELETE | Удаляет объект | удалить запись по ID Важно Не используй POST , PATCH и DELETE в активном workflow без проверки на тестовых данных. Эти методы меняют данные во внешнем сервисе. ## Как передать авторизацию в HTTP Request Авторизация в HTTP Request подтверждает, что workflow имеет право обращаться к API. Самые частые варианты — Bearer token, API key и Basic Auth. ### Bearer token Bearer token передают в заголовке Authorization . ``` Authorization: Bearer {{$env.API_TOKEN}} ``` В n8n это настраивается так: - Включи Send Headers . - Нажми Add Parameter . - В поле Name укажи Authorization . - В поле Value укажи Bearer {{$env.API_TOKEN}} . Безопасность Храни токены в переменных окружения или credentials. Не вставляй production-токены прямо в текст workflow. ### API key API key часто передают в заголовке или query-параметре. ``` X-API-Key: {{$env.EXAMPLE_API_KEY}} ``` Если документация просит query-параметр, добавь его в Send Query Parameters . ``` ?api_key={{$env.EXAMPLE_API_KEY}} ``` ## Как отправить JSON в теле запроса JSON в HTTP Request используют для создания или обновления данных через API. Для этого нужен метод POST , PUT или PATCH . - Выбери Method : POST . - Включи Send Body . - В поле Body Content Type выбери JSON . - В режиме Specify Body выбери Using JSON . - Вставь тело запроса. ``` { "title" : "Позвонить клиенту" , "priority" : "high" , "source" : "n8n" , "customerEmail" : "{{$json.email}}" } ``` Поле {{$json.email}} берёт email из входных данных текущей ноды. Подробнее о подстановках смотри в разделе Выражения . ## Как использовать данные из предыдущих нод Данные из предыдущих нод в HTTP Request вставляют через выражения n8n. Выражение позволяет собрать URL, заголовок или тело запроса динамически. Пример URL с ID клиента: ``` https://api.example.com/v1/customers/{{$json.customerId}} ``` Пример query-параметра: ``` status={{$json.status}} ``` Пример JSON body: ``` { "name" : "{{$json.name}}" , "email" : "{{$json.email}}" , "utm_source" : "{{$json.utm_source || 'unknown'}}" } ``` Как мыслить HTTP Request получает один item, выполняет запрос и возвращает один результат. Если на вход пришло 100 items, нода может выполнить 100 запросов. ## Как обработать ответ API Ответ HTTP Request становится JSON-данными для следующих нод workflow. Эти данные можно фильтровать, преобразовывать и отправлять дальше. Частый сценарий: - HTTP Request получает список объектов. - If проверяет статус или наличие поля. - Set оставляет только нужные поля. - Telegram , Email или CRM-нода отправляет результат. Пример обращения к полю ответа: ``` {{$json.data[0].id}} ``` Если API возвращает массив, проверь структуру ответа через Test step . Затем используй Split Out или Code node, если нужно обработать каждый элемент отдельно. ## Частые ошибки HTTP Request в n8n Ошибки HTTP Request чаще всего связаны с авторизацией, форматом JSON или неверным URL. Код ответа помогает быстро найти причину. - Код | Что значит | Что проверить - 400 | неверный запрос | JSON body, обязательные поля, типы данных - 401 | нет авторизации | токен, заголовок Authorization , срок действия ключа - 403 | нет доступа | права API-ключа, тариф, scope приложения - 404 | endpoint не найден | URL, ID объекта, версию API - 429 | превышен лимит | rate limit, паузы, retry-настройки - 500 | ошибка сервера | статус сервиса, повтор запроса позже Диагностика Сначала проверь тот же запрос в Postman, Insomnia или через curl . Если запрос работает там, перенеси метод, URL, headers и body в n8n без изменений. ## Пример: отправка лида в CRM через API HTTP Request может отправить лид из формы в CRM без готовой интеграции. Для этого workflow принимает данные, собирает JSON и вызывает endpoint CRM. Схема workflow: - Webhook принимает заявку с сайта. - Set нормализует имя, телефон и email. - HTTP Request отправляет данные в CRM. - If проверяет успешный статус ответа. - Telegram уведомляет менеджера. ``` { "name" : "{{$json.name}}" , "phone" : "{{$json.phone}}" , "email" : "{{$json.email}}" , "comment" : "Заявка с сайта" , "source" : "website" } ``` Для production-сценария добавь обработку ошибок. Базовые принципы описаны в разделе Обработка ошибок . ## LLM-разметка статьи LLM-разметка помогает поисковым и AI-системам извлекать из статьи точные ответы. Ниже собраны основные сущности и факты страницы. ``` { "topic" : "n8n HTTP Request" , "definition" : "n8n HTTP Request — нода для отправки HTTP-запросов к внешним API из workflow." , "primary_use_cases" : [ "подключение REST API" , "создание записей во внешних сервисах" , "получение данных из API" , "отправка webhook-событий" ], "required_parameters" : [ "URL" , "HTTP method" , "authentication" , "headers" ``` ## Часто задаваемые вопросы ### Можно ли подключить любой API к n8n через HTTP Request? Да. Если API доступен по HTTP и у тебя есть права доступа, его можно подключить через HTTP Request. Ограничения обычно связаны с авторизацией, rate limit или закрытой сетью. ### Что делать, если HTTP Request возвращает 401? 401 означает ошибку авторизации. Проверь токен, формат заголовка Authorization , срок действия ключа и права доступа приложения. ### Чем HTTP Request отличается от готовых нод n8n? HTTP Request универсальнее готовой ноды. Готовая нода удобнее для типовых операций, а HTTP Request нужен для нестандартных endpoint и сервисов без интеграции. ### Как не превысить лимит API? Используй паузы, batching и retry-логику. Если API возвращает 429 , уменьши частоту запросов и проверь лимиты в документации сервиса. ### Где хранить API-ключи для HTTP Request? API-ключи лучше хранить в credentials или переменных окружения. Не храни секреты в открытом тексте внутри workflow. ## Как проверять код и expressions Страницу «n8n HTTP Request» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным. Базовый источник для проверки: payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом. Главный риск — принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость. - Слой | Что зафиксировать | Зачем - Вход | 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, пустой вход, повтор и сбой внешнего сервиса для «n8n HTTP Request» | делает статью пригодной для 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 по теме ## Связанные материалы - Выражения в n8n — как подставлять данные из предыдущих нод. - Работа с данными — как преобразовывать JSON между шагами workflow. - Обработка ошибок — как строить устойчивые сценарии. - Первый workflow за 10 минут — базовый пример с HTTP Request и Telegram. ## Production-чеклист для подключения API Используйте этот блок как быстрый контроль перед публикацией workflow или изменением существующей автоматизации. Он не заменяет staging, но помогает поймать самые частые отказы заранее. - Перед запуском: описать auth flow, headers, body, rate limit и формат ошибок API. - Минимальный тест: сделать запрос с валидным и невалидным токеном, проверить обработку 401/403/429. - Типовой отказ: workflow считает HTML-страницу ошибки валидным JSON-ответом. - Что логировать: входной payload без секретов, статус внешнего API, branch ошибки, execution id и владельца процесса. Критерий готовности: сценарий проходит успешный путь, ошибочный путь и повтор события без дублей, потери данных и неконтролируемого падения execution. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.