n8n + NeuroAPI: HTTP Request и ключ API

n8n поддерживает два практических сценария. Первый — универсальный HTTP Request: вы сами формируете тело запроса и управляете всеми полями, а официальная документация n8n описывает для него типы аутентификации, включая Header Auth и Bearer Auth. Второй — встроенные узлы OpenAI: в части версий n8n у креденшела OpenAI есть поле Base URL, но официальная страница креденшела описывает только API Key и Organization ID, поэтому наличие поля нужно проверить в своей версии.

Если поле Base URL в вашей версии отсутствует, не изобретайте обходных путей: используйте HTTP Request. Такой workflow полностью прозрачен, его легко экспортировать и ревьюить, а поддержка не зависит от обновлений узла. Для первого сценария часто достаточно одного HTTP Request и одного Set-узла для разбора ответа.

• HTTP Request — работает всегда, полный контроль над телом и заголовками.
• OpenAI-узел — удобнее для готовых операций, но Base URL зависит от версии.
• Проверять версию n8n и документацию креденшела стоит до сборки production-workflow.

Документация n8n описывает Header Auth как креденшел с двумя полями: имя заголовка и значение. Для NeuroAPI имя — Authorization, значение — Bearer <ключ>. Альтернатива — Bearer Auth, который по документации является частным случаем Header Auth с заголовком Authorization. В обоих случаях ключ хранится в защищённом хранилище n8n и подставляется в каждый запрос.

Не храните ключ в параметрах узла и не передавайте его в URL: такие значения попадают в экспорт workflow и в логи. Если workflow используется командой, заведите отдельный ключ NeuroAPI под этот сценарий — так расход автоматизации будет виден отдельно от ручных экспериментов и других интеграций.

• Header Auth: Name = Authorization, Value = Bearer <ключ>.
• Bearer Auth: только значение токена.
• Отдельный ключ под n8n — прозрачный расход.
• Не вставляйте ключ в URL или тело запроса.

Узел HTTP Request настраивается так: Method POST, URL https://neuroapi.host/v1/chat/completions, Authentication — Header Auth, Send Body включён, Specify Body — JSON. Тело повторяет OpenAI-совместимый формат: model с точным ID из каталога, messages с ролью и содержимым, при необходимости temperature и max_tokens.

В ответе будет структура OpenAI-совместимого Chat Completions: choices с сообщением ассистента и поле usage с числом входных и выходных токенов. Для workflow удобно добавить Set-узел, который вытащит текст ответа и usage в отдельные поля, — тогда последующие узлы не зависят от полной структуры ответа.

• Method: POST; URL: https://neuroapi.host/v1/chat/completions.
• Send Body: JSON; model — точный ID из /price.
• messages — массив объектов с role и content.
• Response: choices[0].message.content и usage.

Типовой сценарий: триггер (Webhook, Telegram, расписание) → подготовка данных → HTTP Request к NeuroAPI → разбор ответа → действие (отправка сообщения, запись в таблицу, создание задачи). Такая цепочка остаётся понятной, а каждый шаг можно протестировать отдельно и увидеть в истории выполнений n8n.

Для диалоговых сценариев храните историю сообщений самостоятельно: Chat Completions stateless, поэтому клиент передаёт всю нужную историю в messages. Не отправляйте бесконечно растущий контекст — ограничивайте число последних сообщений и суммаризируйте старое, иначе расход и задержка будут расти с каждым ходом.

Отдельно продумайте идемпотентность: повторный запуск по расписанию не должен создавать дубликаты задач и повторно отправлять уже выполненный запрос. Сохраняйте идентификатор запуска и проверяйте его перед вызовом модели, а результат записывайте вместе с usage — тогда историю расхода можно восстановить даже после перезапуска n8n.

• Триггер → подготовка → HTTP Request → разбор → действие.
• Тестируйте каждый шаг отдельно в history n8n.
• Для чата передавайте ограниченную историю в messages.
• Не пересылайте весь диалог без ограничения — контекст дорожает.

Ошибочные ответы стоит разбирать по коду: 401 — ключ не принят, 404 — неверный ID модели или эндпоинта, 429 — превышение лимита запросов, 5xx — временная проблема на стороне маршрута. Для 429 и 5xx настройте в узле повтор с задержкой, но не делайте повторы бесконечными: дорогой запрос, повторённый несколько раз, списывается каждый раз, если он дошёл до выполнения.

Баланс NeuroAPI предоплаченный, списание идёт по фактическому использованию, поэтому перед production-workflow полезно оценить объём: число запусков в сутки, средний размер контекста, нужную модель. Health-check удобно строить отдельно: дешёвый запрос по расписанию проверяет ключ и баланс, а алерты по 401 и 429 ловят проблемы до того, как они затронут пользователей.

• 401 — ключ, 404 — ID модели и путь, 429 — лимиты, 5xx — временная ошибка.
• Повторы — только с ограничением попыток и задержкой.
• Оцените число запусков и средний контекст до production.
• Проверяйте идемпотентность повторных запусков.
• Отдельный health-check по расписанию экономит время.