Запрос «n8n api» на практике закрывает две разные задачи. Первая и самая частая — подключить к сценарию чужой сервис: систему учёта, платёжный шлюз, сервис генерации изображений, языковую модель. Вторая — собственный REST API самой платформы, через который своей установкой n8n управляют снаружи. Эта статья про первую задачу: как подключить n8n к внешнему сервису, когда для него есть готовая нода, и что делать, когда её нет.
Материал опирается на документацию n8n и на два русскоязычных видеоразбора, где авторы настраивают запросы прямо в кадре — вместе с теми местами, где всё ломается. Устройство нод, установку платформы и сборку ИИ-агента текст не пересказывает: они разобраны отдельно, ссылки стоят там, где тема всплывает.
Два пути подключения любого сервиса
Способов поговорить с чужим сервисом у n8n ровно два, и выбор между ними определяет всю дальнейшую настройку.
Первый способ — готовая нода. Каталог интеграций n8n собран из отдельных нод под конкретные сервисы: у каждой свой набор действий вроде «добавить строку», «отправить сообщение», «создать запись», и свой тип учётных данных. Подключение сводится к трём шагам: выбрать ноду, создать в ней credential, указать действие. Как именно устроен запрос к сервису, знать не нужно — нода собирает его сама.
Простота готовой ноды обманчива ровно настолько, насколько сложен сам сервис. У Telegram всё коротко: в учётных данных одно поле, куда вставляется токен, выданный служебным ботом; этот путь целиком разобран в материале про телеграм-бота с нейросетью. У Google цепочка длиннее, и готовая нода её не отменяет. По документации порядок такой: создать проект в Google Cloud Console, включить в нём нужный API (для Sheets и Docs дополнительно потребуется Google Drive API), настроить экран согласия, создать учётные данные типа OAuth client ID с приложением Web application, перенести туда OAuth Redirect URL, который n8n показывает в своём credential, а обратно в n8n вписать Client ID и Client Secret. Только после этого кнопка входа через Google делает то, ради чего затевалась.
Второй способ — нода HTTP Request. Это универсальный блок, который отправляет обычный запрос по указанному адресу и кладёт ответ в сценарий. Именно её имеют в виду, когда ищут «n8n http request». Она нужна в трёх случаях: готовой ноды для сервиса не существует; готовая нода есть, но нужного действия в ней нет; сервис свой собственный и никакой ноды для него не будет никогда.
Практическое правило простое. Сначала стоит поискать сервис по названию в списке нод — если он там есть, настройка займёт меньше времени и меньше нервов. Если в списке пусто, открывается документация сервиса и берётся HTTP Request. Всё остальное в этой статье — про второй путь.
Credentials: как n8n хранит ключи
Учётные данные в n8n живут отдельно от сценариев. Это принципиальное решение платформы, и оно решает сразу несколько задач.
Создаются они двумя путями. Из общего списка — кнопка Create, затем Credential, затем выбор сервиса и заполнение полей. Или прямо из ноды, в которой понадобился доступ, — тогда после сохранения credential сразу подставляется в эту ноду. При сохранении n8n самостоятельно проверяет введённые данные: если сервис поддерживает такую проверку, вы сразу увидите, принял он ключ или нет.
Дальше ключ уходит в базу не как есть. Документация описывает механизм так: перед записью содержимое учётных данных шифруется отдельным ключом, а сам этот ключ создаётся при первом запуске и лежит в служебной папке n8n. Если нужно задать его самому — например, чтобы одинаковый ключ использовали несколько экземпляров платформы, — он передаётся переменной окружения N8N_ENCRYPTION_KEY. Какой именно алгоритм применяется, в документации не сказано, так что заявлений вида «шифруется по такому-то стандарту» лучше не повторять.
Отдельного внимания заслуживает поле Allowed HTTP Request Domains в учётных данных. Оно ограничивает список доменов, к которым этот credential разрешено применять в ноде HTTP Request: все домены, только перечисленные или ни одного. Смысл прямой — ключ не уедет случайным запросом на посторонний адрес.
Ещё credential можно расшарить другому пользователю или проекту. Получатель сможет им пользоваться в своих сценариях, но не увидит содержимое полей и не сможет их отредактировать. Из этого же вытекает главная причина не вставлять ключ прямо в поле ноды — её хорошо формулирует автор одного из разборов:
как этот ключ спрятать: вдруг вы захотите потом создать такой сценарий и кому-то его дать попользоваться, чтобы не было видно вашего апи ключа, когда вы будете делиться этим блюпринтом
— Данил Курилов, «Как подключить HTTP ноду в n8n — просто и без страха»
Ключ, вписанный в заголовок запроса руками, уезжает вместе с выгруженным сценарием любому, кому вы его передали. Ключ, спрятанный в credential, не уезжает.
Нода HTTP Request: разбор
Нода умеет отправлять запросы методами DELETE, GET, HEAD, OPTIONS, PATCH, POST и PUT — то есть покрывает всё, что обычно требует документация стороннего сервиса.
Авторизация в ней бывает двух видов, и разница между ними важна. Predefined credential type — это готовый тип учётных данных для сервиса, который платформа знает: вы выбираете сервис из списка, и нода сама понимает, куда подставлять ключ. Generic credentials — ручной режим для любого API. Типов здесь семь: Basic, Custom, Digest, Header, OAuth1, OAuth2 и Query auth. Выбор диктует документация сервиса: где-то ключ идёт заголовком, где-то параметром в адресе, где-то через процедуру входа.
Заполнять поля вручную приходится не всегда. У ноды есть импорт команды cURL: вы вставляете готовую команду, а нода раскладывает её по своим полям — адрес, метод, заголовки, тело. Автор разбора про парсинг авиабилетов показывает обходной приём для случая, когда сервис документирует запрос иначе:
Чтобы не мучиться и не заполнять всё это дело, мы просто возьмём, вставим это в чат GPT и напишем ему: преобразуй в curl […] И вот здесь вот есть как раз импорт curl. Сюда вставляем. И видите, он сам вставил все необходимые параметры
— канал USMFOX AI, «n8n 2.0 уроки. Урок 5. API HTTP Request»
Одна оговорка от документации: при импорте параметры попадают в поля как строки. Если сервис ждёт число или логическое значение, тип придётся поправить руками.
Ответ настраивается в дополнительных параметрах. Response Format выбирает, как трактовать пришедшее: автоопределение, файл, JSON или текст. Отдельным переключателем к результату добавляются заголовки ответа и код статуса — это выручает, когда сервис сообщает о лимитах именно заголовками. Never Error заставляет ноду считать успешным любой ответ и не останавливать сценарий на коде ошибки: полезно, когда разбирать ошибку вы собираетесь сами, дальше по цепочке. Timeout задаёт в миллисекундах, сколько ждать ответа, прежде чем считать запрос неудавшимся.
Там же лежит пагинация — на случай, когда сервис отдаёт данные страницами. Настраивается она в двух режимах: подставлять в каждый следующий запрос изменённый параметр либо брать адрес следующей страницы прямо из ответа. Внутри доступны служебные переменные $pageCount, $request и $response.
Пример настройки под живой API
Разбор с открытым API поиска авиабилетов показывает минимальный набор действий. Метод — GET. Дальше заполняются параметры запроса, которые уйдут в адрес:
Здесь у нас есть метод get, и можно заполнять вот, допустим, квери [query] параметры, которые мы будем передавать внутри запроса
Последним добавляется ключ доступа — в том виде, в каком его требует сервис. У автора это отдельный параметр запроса, и вся операция сводится к тому, чтобы скопировать значение из личного кабинета сервиса и вставить в поле. Если бы сервис требовал передавать ключ заголовком, порядок был бы другим, и автор проговаривает это прямо: какие именно заголовки нужны, полагается узнавать из документации сервиса.
Дальше начинается самое ценное в разборе — грабли. Запрос отрабатывает, нода зелёная, а данных нет:
результат true, то есть наш апи-запрос отработал. Но вы можете спросить, почему он пустой […] в этом примере у нас указан 2023 год. Соответственно, он и не нашёл авиабилетов по этой причине
Вывод общий для любого API: успешный ответ и полезный ответ — разные вещи. Пустой результат при коде успеха почти всегда означает, что параметры запроса технически верны, но описывают то, чего у сервиса нет — прошедшую дату, несуществующий идентификатор, слишком узкий фильтр. Проверять в такой ситуации нужно не настройки ноды, а смысл переданных значений.
Второй практический момент из того же разбора: ответ редко приходит в удобном виде. Автор называет сырой результат грязным и разбирает его отдельной нодой Split, оставляя только нужную часть данных, — после этого следующие ноды получают чистый список, а не вложенную структуру.
Авторизация Bearer через Header Auth
Самый распространённый способ авторизации у современных API — заголовок с ключом. В n8n он собирается через generic-тип Header Auth, и разбор с генерацией изображений показывает это по шагам.
В ноде HTTP Request выбирается авторизация типа Generic, затем Header Auth, затем создание новых учётных данных. Полей внутри два. В поле Name пишется имя заголовка — Authorization. В поле Value — слово Bearer, пробел и сам ключ. После сохранения credential получает имя и появляется в списке: в следующей ноде того же сервиса его достаточно выбрать из выпадающего списка, заново вставлять ключ не нужно.
Выбираем здесь хедер аус [Header Auth]. […] в name мы подставляем authorization […] сюда value вставляем Bearer и [ключ]. И нажимаем сейв. Всё, у нас сохранилось
— Данил Курилов
Дальше в том же разборе собирается схема, типичная для любого сервиса, который работает не мгновенно. Сервис генерации изображений не отдаёт картинку в ответ на запрос — он ставит задачу в очередь. Отсюда цепочка из трёх звеньев.
Первое звено — POST с телом в формате JSON, куда подставляется текст запроса к модели. Ответ приходит почти сразу, но вместо результата в нём лежит идентификатор задачи и код успеха. Автор описывает это буквально: передаём запрос, получаем идентификатор задачи и подтверждение, что она принята.
Второе звено — проверка статуса. Идентификатор из первого ответа подставляется в следующий запрос, а результат проверяется нодой If: если статус означает готовность, сценарий идёт по ветке «истина» и забирает результат; если нет — возвращается к проверке.
если статус равен саксес [success], то мы идём по линии true. Если же статус не равен саксес, то мы идём заново генерить картинку. И он её будет вот так прогонять, пока не будет статус правильный […] чтобы вы зря не потратили токены
Третье звено — получение результата. Когда статус наконец говорит о готовности, GET-запрос забирает ответ, в котором уже лежит ссылка на готовый файл.
Эту схему стоит запомнить целиком: по ней работают почти все сервисы генерации изображений, видео и звука. Тот, кто ждёт готовый файл в ответе на первый же запрос, обычно получает пустоту и решает, что API сломан.
Пример: подключить нейросеть по API
Отдельный случай, ради которого в n8n чаще всего берут ноду HTTP Request, — подключить нейросеть напрямую, без готовой подноды. Формат запроса здесь стандартизирован де-факто: большинство сервисов повторяет схему OpenAI.
Метод — POST, адрес заканчивается на /v1/chat/completions. Заголовков два: Authorization со словом Bearer и ключом (то есть тот самый Header Auth из предыдущего раздела) и Content-Type со значением application/json. В теле обязательных полей тоже два — идентификатор модели и массив сообщений, где у каждого указана роль и содержимое:
{
"model": "идентификатор модели",
"messages": [
{ "role": "user", "content": "текст запроса" }
]
}Всё остальное необязательно: ограничение на длину ответа, температура, потоковая выдача, описание инструментов. Ответ приходит в JSON, и текст модели забирается выражением из нужного поля — так же, как любые другие данные между нодами.
Шлюз GEN202 отвечает по этому же формату, поэтому в ноду подставляется адрес https://api.gen202.com/v1/chat/completions, а в заголовок — ключ GEN202. Смысл в том, что ключ один на весь каталог моделей: чтобы переключиться на другую модель, меняется значение поля model, а учётные данные и вся остальная настройка ноды остаются прежними. Новому аккаунту начисляются приветственные 50 кредитов (25 ₽) — их хватает, чтобы собрать сценарий и проверить связку до первого пополнения. Тот же ключ можно завести не в HTTP Request, а в подноде Chat Model, подменив в её учётных данных адрес шлюза, — этот путь со всеми оговорками разобран в материале о том, как создать ИИ-агента в n8n.
Приём данных: нода Webhook
До сих пор речь шла об исходящих запросах. Обратное направление устроено зеркально: n8n умеет не только стучаться к чужим сервисам, но и принимать обращения к себе. За это отвечает нода Webhook — вебхук n8n на входе сценария.
Нода выдаёт два адреса, и путать их не стоит. Test URL работает только во время отладки: вы нажимаете «Listen for Test Event», и n8n ждёт входящий запрос — по документации ожидание длится 120 секунд. Пришедшие данные при этом видны прямо в редакторе, что удобно, когда нужно понять, в каком виде сервис их присылает. Production URL регистрируется, когда сценарий опубликован, работает постоянно, и результаты каждого срабатывания складываются в раздел Executions.
Методы приёма почти те же, что у HTTP Request: DELETE, GET, HEAD, PATCH, POST и PUT, но OPTIONS среди них нет. Путь адреса может содержать параметры — сегмент вида /:variable превращается в переменную, значение которой доступно внутри сценария.
Отдельно настраивается, что вебхук ответит вызывающей стороне. Вариантов три: ответить немедленно служебным подтверждением о том, что сценарий запущен; дождаться окончания сценария и вернуть данные последней ноды; полностью описать ответ отдельной нодой Respond to Webhook — тогда вы сами задаёте код, заголовки и тело. Есть и режим потокового ответа, если данные должны уходить по мере готовности.
Открытый адрес без защиты стоит отдавать наружу с осторожностью, и в ноде для этого есть выбор авторизации: Basic, заголовок с ключом, JWT или ничего.
Одно ограничение касается облачной версии. По разделу документации о частых проблемах, ответ вебхука на n8n Cloud должен уложиться в 100 секунд, иначе вызывающая сторона получает код 524; для долгих сценариев документация предлагает схему из двух вебхуков — первый принимает задачу и сразу отвечает, второй сообщает результат, когда он готов. Для самостоятельно поднятой версии общего предела в документации не названо, так что переносить сюда сотню секунд как универсальное число не нужно.
Частный случай приёма — сообщения от Telegram: там адрес регистрирует сама нода-триггер, а требования к нему разобраны в отдельном материале, ссылка на который есть в первом разделе.
Данные между нодами: выражения
Любое подключение бесполезно, пока данные не переезжают из ноды в ноду. За это в n8n отвечают выражения — вставки в двойных фигурных скобках, которые вычисляются в момент выполнения.
Обращение к данным текущего входа выглядит как {{ $json.body.city }} — то есть поле city внутри объекта body того элемента, который пришёл в ноду. Обращение к данным другой ноды делается по её имени: {{ $('Webhook').item.json.headers.authorization }}. Так подставляют идентификатор задачи из предыдущего ответа, номер чата из входящего сообщения, ключ из заголовка — всё, что уже лежит где-то в сценарии.
Внутри скобок работает JavaScript, а для выборки из вложенных структур доступен JMESPath. Если преобразований много, их удобнее вынести в ноду Edit Fields (Set), а не разводить логику по десятку полей.
Полезная деталь, о которой мало кто знает: выражения работают и в полях учётных данных. Это позволяет, например, собирать значение заголовка из нескольких частей, не вписывая его целиком.
Что такое элементы данных, почему нода выполняется столько раз, сколько их пришло, и как читать JSON в интерфейсе — это основы, разобранные в статье n8n: что это.
Лимиты и повторы
Чужой API почти всегда ограничивает частоту обращений, и первое же массовое срабатывание сценария в это ограничение упирается. В n8n есть два механизма на этот случай, и они дополняют друг друга.
Batching настраивается в дополнительных параметрах ноды HTTP Request: параметр Items per Batch задаёт, сколько элементов обрабатывать за раз, а Batch Interval — паузу между партиями в миллисекундах. В примере из документации пауза равна 1000 миллисекундам, то есть одной секунде.
Retry On Fail живёт в настройках ноды и включается отдельным переключателем. Параметров два: сколько попыток сделать и сколько ждать между ними. Для сервиса, который допускает один запрос в секунду, документация советует ставить паузу в 1000 миллисекунд. Значения, стоящие в этих полях по умолчанию, в документации не приводятся — их проще посмотреть в своей установке, чем искать в статьях.
Третий вариант, когда нужен полный контроль над ритмом, — связка ноды Loop Over Items с нодой Wait: цикл идёт партиями, а пауза задаётся явным шагом.
Сюда же относится ошибка, о которой предупреждает автор разбора про авиабилеты, и она не связана с лимитами сервиса напрямую — она просто умножает число запросов на пустом месте. По умолчанию нода срабатывает столько раз, сколько элементов пришло на вход: если предыдущая нода выдала сотню строк, запрос уйдёт сотню раз, хотя нужен был один. Лечится это переключателем в настройках ноды, который заставляет её выполниться единожды за запуск, — автор советует ставить его сразу, чтобы не разбираться потом, откуда взялись лишние обращения.
MCP: агентный протокол в n8n
Поддержка MCP в n8n — это три разные ноды, и путаница между ними стоит времени. Запрос «n8n mcp» одинаково часто означает и «отдать наружу», и «взять снаружи», а ноды для этого разные.
MCP Server Trigger превращает сценарий в MCP-сервер. Нода выдаёт адрес, к которому подключаются внешние клиенты и вызывают инструменты, собранные вами в n8n. Транспорта поддерживается два: SSE и streamable HTTP; локальный запуск через стандартный ввод-вывод не поддерживается. Доступ закрывается авторизацией по Bearer или по заголовку.
MCP Client Tool — поднода для ИИ-агента, работающая в обратную сторону: она подключает агента n8n к внешнему MCP-серверу и отдаёт ему тамошние инструменты. Подключение идёт по SSE-адресу, а список инструментов фильтруется — все, только выбранные или все за исключением перечисленных.
MCP Client — обычная нода, а не поднода агента. Она вызывает инструменты MCP-сервера как рядовой шаг сценария, без всякой языковой модели в цепочке.
Все три появились в версии 1.88.0: по записи о релизе на GitHub она вышла 10 апреля 2025 года, в самой документации версия не названа. Если в вашей установке этих нод нет, дело в версии платформы.
Community nodes: когда готовой ноды нет, а HTTP мало
Иногда сервис существует, готовой ноды в n8n для него нет, а собирать десяток запросов вручную не хочется. Тогда остаётся третий путь — нода, написанная сообществом.
Устанавливаются такие ноды через Settings, раздел Community Nodes, кнопка Install и имя пакета в npm; версию можно указать явно, дописав её через собаку. Право на установку есть только у владельца или администратора и только в самостоятельно поднятой версии. Часть пакетов заблокирована — у n8n есть список запрещённых к установке.
Перед установкой платформа просит поставить галочку о том, что вы понимаете риски, и это не формальность. В документации прямо сказано, что такие ноды имеют полный доступ к машине, на которой работает n8n, и способны на любые действия, включая вредоносные. Там же отмечено, что любая используемая вами нода сообщества получает доступ к данным ваших сценариев.
Отсюда практическая граница. Ноды со статусом verified прошли проверку n8n и устанавливаются из встроенного списка. Всё, что ставится по имени пакета из npm, — непроверенный чужой код на вашем сервере рядом с вашими ключами. Если сервис нужен ради двух-трёх запросов, безопаснее собрать их нодой HTTP Request, а не тянуть пакет ради удобства.
Частые вопросы
Что вообще означает «n8n api»? Два разных предмета. Первый — подключение чужих API к сценариям, о чём вся эта статья. Второй — собственный REST API n8n, через который платформой управляют программно, не заходя в интерфейс; его описание живёт в отдельном разделе документации: docs.n8n.io/connect/n8n-api.
Как подключить сервис, для которого нет готовой ноды? Через ноду HTTP Request. Порядок такой: открыть документацию сервиса, найти адрес и метод нужного запроса, выбрать способ авторизации (чаще всего заголовок с ключом через Header Auth), заполнить параметры или тело. Если в документации есть готовая команда cURL, её можно импортировать в ноду и не заполнять поля руками.
Безопасно ли хранить ключи внутри n8n? Ключи хранятся не в сценарии, а в отдельных учётных данных, и перед записью в базу шифруются. Пользователь, которому credential расшарили, не видит его содержимого. Дополнительно можно ограничить домены, к которым разрешено применять этот credential. Главный риск смещается в другую сторону: ключ, вписанный прямо в поле ноды, уедет вместе с выгруженным сценарием, а нода сообщества, установленная из npm, имеет доступ ко всему, что происходит на сервере.
Чем вебхук отличается от ноды HTTP Request? Направлением. HTTP Request — это исходящий запрос: сценарий сам обращается к чужому сервису и ждёт ответ. Вебхук — входящий: чужой сервис обращается к n8n по выданному адресу и запускает сценарий. Первое ставится в середине цепочки, второе — только в начале.
Как подключить нейросеть к n8n одним ключом?
Понадобится ключ шлюза, совместимого с форматом OpenAI. В ноде HTTP Request указывается метод POST, адрес вида https://api.gen202.com/v1/chat/completions, заголовок Authorization со словом Bearer и ключом, а в теле — идентификатор модели и массив сообщений. Смена модели после этого сводится к смене одного поля в теле запроса: заводить отдельный аккаунт и отдельные учётные данные под каждого поставщика не нужно.