Автоматизация приёма заказов в n8n: подключение Claude API

Сценарий: каждый день вручную отвечаете на сообщения о заказах, не успеваете

В локальном бизнесе — общепите, рознице, совместных закупках — сообщения о заказах обычно приходят в WeChat, формы или бэк-офис магазина. Схема неизменна: приходит новый заказ, вы смотрите содержимое, определяете, это обычный заказ или жалоба, и отправляете подтверждающее сообщение. Пока заказов мало, это не проблема, но как только объём растёт, большая часть времени уходит на повторяющиеся ответы.

Цель этого руководства конкретна: собрать в n8n автоматизированный конвейер, в котором после поступления нового заказа ИИ автоматически определяет намерение и генерирует ответ, обычные заказы обрабатываются автоматически, а заказы-жалобы пересылаются оператору вместе с уведомлением. Всё без написания кода, для подключения модели нужен только API key HiAPI.

С 2026 года n8n регулярно рекомендуют малому и среднему бизнесу в обзорах инструментов автоматизации (например, в годовых обзорах Atlassian и techaigoz за 2026 год), и причина проста: self-hosting, открытый исходный код, зрелая система LLM-узлов. В октябре 2026 года один пост в X об автоматизации приёма заказов для локального малого бизнеса с помощью n8n набрал около 51 тыс. просмотров — спрос на это уже массовый.

Подготовка: один key HiAPI + один n8n

Перед началом нужно всего две вещи.

Во-первых, API key HiAPI. Создайте его в консоли HiAPI и скопируйте — он начинается с sk-. Этот key совместим с OpenAI, и все модели в n8n в дальнейшем работают через него.

Во-вторых, n8n. Подойдёт облачная версия или self-hosting, это руководство не привязано к способу развёртывания. Единственное требование — версия не должна быть слишком старой, почему — объясним ниже.

Ключевой шаг: узел OpenAI Chat Model подключается к HiAPI

Основа всего конвейера — подключить n8n к модели. Это проще, чем кажется: в системе AI-узлов n8n есть дочерний узел OpenAI Chat Model, в его Credential есть поле Base URL — достаточно указать OpenAI-совместимую конечную точку и API Key (эта возможность давно обсуждается в сообществе n8n, см. пост Override baseURL for OpenAI Node).

Заполните три поля:

1. Base URL: https://api.hiapi.ai
2. API Key: ваш key HiAPI (начинается с sk-)
3. Model: укажите вручную deepseek-v4.1-flash

Обратите внимание на два момента. Во-первых, нужен именно дочерний узел OpenAI Chat Model из системы AI-узлов, а не старый узел OpenAI. Во-вторых, поле Base URL есть только в более новых версиях n8n; в некоторых старых версиях этого поля нет — сначала обновите n8n до более новой версии, затем настраивайте.

После заполнения все AI-узлы во всём рабочем процессе используют этот один Credential. Чтобы позже сменить модель, достаточно изменить поле Model — например, для жалоб указать claude-opus-4-8, key при этом менять не нужно.

На этом модель подключена. Далее — сам рабочий процесс.

Четыре шага рабочего процесса

Весь конвейер — четыре узла, соединённых последовательно: триггер Webhook, ИИ-классификация с подготовкой ответа, ветвление IF, уведомление.

1. Триггер Webhook

В качестве точки входа используйте узел Webhook: когда в системе заказов (форма, бэк-офис магазина, промежуточный бот) появляется новый заказ, содержимое сообщения отправляется POST-запросом на этот адрес. Текст заказа, полученный триггером, передаётся дальше в ИИ-узел.

Если пока нет интеграции с системой, можно сначала вручную имитировать новые заказы через узел формы n8n, прогнать процесс и затем заменить на реальный источник данных.

2. ИИ-узел: классификация + подготовка ответа

Подключите узел AI Agent (или упрощённый узел Chain), привяжите настроенный ранее Credential OpenAI Chat Model, в поле модели укажите deepseek-v4.1-flash. Системный prompt выполняет две задачи: определяет, является ли сообщение обычным заказом или жалобой, и затем составляет ответ в тоне продавца для каждого случая.

Ниже — готовый системный prompt, замените название магазина и категорию на свои, и он заработает:

Ты — помощник по приёму заказов локального заведения общепита. Обрабатывай каждое сообщение пользователя по следующим правилам:

1. Сначала определи тип сообщения:
   - Обычный заказ: пользователь явно оформляет заказ, указаны товары, количество, адрес или способ получения
   - Жалоба: пользователь выражает недовольство товаром или обслуживанием, требует возврат, подаёт претензию
   - Прочее: вопросы о часах работы, меню и прочее, не требующее немедленного ответа

2. Затем сгенерируй ответ по типу:
   - Обычный заказ: в тоне продавца подтверди содержимое заказа, повтори товары и количество, укажи ориентировочное время готовности или доставки, тон приветливый и естественный
   - Жалоба: сначала вырази сожаление и внимание, сообщи, что в ближайшее время вопрос будет передан оператору, не обещай конкретных компенсаций
   - Прочее: нормально ответь на вопрос пользователя

3. Формат вывода строго JSON, два поля:
   - category: order / complaint / other
   - reply: подготовленный текст ответа

Выводи только JSON, без каких-либо пояснений.

Ключевой момент — требовать от ИИ структурированный JSON, чтобы последующее ветвление IF работало стабильно. Если иногда вывод нестандартный, добавьте после ИИ-узла простой шаг очистки данных как страховку.

3. Ветвление IF: обычные заказы — автоматически, жалобы — оператору

Используйте узел IF для чтения поля category:

• order или other: автоматический ответ — текст reply отправляется клиенту через ваш канал уведомлений (бот WeChat, email или SMS — зависит от того, что подключено)
• complaint: без автоматического ответа — исходный текст заказа и результат классификации отправляются владельцу или дежурному сотруднику с предложенным текстом ответа, ожидается вмешательство человека

Именно в этом разделении и заключается ценность конвейера. ИИ берёт на себя большую часть повторяющихся подтверждающих сообщений, а человек занимается только жалобами, где нужны суждение и эмпатия.

4. Узел уведомлений

В конце подключите узел уведомлений, отправляющий результат обработки в ваш инструмент совместной работы (Feishu, WeChat, email — любой). Для обычного заказа — уведомление, что ответ отправлен автоматически; для жалобы — полная информация о заказе с пометкой «требуется оператор». Так вы будете в курсе происходящего в магазине в реальном времени, даже не следя за историей выполнения конвейера.

Контроль затрат: обычное — на flash, сложное — на opus

Выбор модели под задачу — ключ к контролю затрат в этом процессе; не нужно использовать самую дорогую модель для всех запросов.

• Обычная классификация и ответы — на deepseek-v4.1-flash, вход $0.44 / млн токенов, выход $1.32 / млн токенов (цена платформы HiAPI, по состоянию на 2026-10). Сообщение о заказе обычно занимает несколько сотен токенов, стоимость модели на один заказ очень низкая — по оценке, менее 1 цента
• Анализ жалоб, обобщение длинного контекста и другие сложные сценарии — переключайте на claude-opus-4-8, вход $2.29 / млн токенов, выход $11.47 / млн токенов (по состоянию на 2026-10). Доля жалоб мала, влияние на общие затраты ограничено

О ценах — кратко, подробное ценообразование смотрите на странице модели. Чтобы глубже понять, почему выбор модели под задачу экономит затраты, читайте нашу статью Практика автоматической маршрутизации в Notion AI — там полный подход к распределению запросов по разным моделям в зависимости от задачи, та же логика, что и в этом сценарии приёма заказов.

FAQ

Безопасно ли хранить API key в n8n?

Key нужно указывать в Credential (учётных данных) n8n, а не прописывать напрямую в параметрах узла или коде. Credential хранится в n8n в зашифрованном виде и не попадает в экспорт рабочего процесса при совместном использовании. Кроме того, рекомендуем установить в консоли HiAPI лимит использования для этого key — даже при утечке потери будут контролируемыми.

Что делать при 429 (слишком частые запросы)?

429 означает срабатывание ограничения частоты. Сначала проверьте, не загружается ли большое количество заказов пакетом за короткое время — можно увеличить интервал срабатывания или добавить очередь для ИИ-узла. Если ошибка повторяется, проверьте в консоли HiAPI настройки параллелизма и квоты текущего key, при необходимости измените тариф. В рабочем процессе также можно настроить для ИИ-узла стратегию повторных попыток: при 429 автоматически повторить после задержки.

Можно ли использовать другие модели?

Да. Достаточно заменить поле Model на название любой модели HiAPI, например обычные заказы — на deepseek-v4.1-flash, жалобы — на claude-opus-4-8, key и Base URL менять не нужно. Один key работает со всеми моделями — в этом и удобство использования HiAPI вместо отдельной регистрации в каждом официальном сервисе.

В чём разница с прямым получением официальных API key?

Главных отличий два. Во-первых, один key HiAPI покрывает несколько моделей — не нужно отдельно регистрироваться, пополнять баланс и управлять квотами на каждой официальной платформе. Во-вторых, единый расчёт по факту использования — выгоднее в сценариях, где вызовы распределены между несколькими моделями. Для малого и среднего бизнеса стоимость управления важнее разницы в цене за единицу.

Имеет ли значение, что потоковый вывод (streaming) не поддерживается?

Нет. Этот конвейер обрабатывает заказы асинхронно — ИИ генерирует ответ и возвращает его целиком, в отличие от чат-интерфейса, где нужен посимвольный вывод. Наличие или отсутствие streaming на результат не влияет.

Что делать, если в n8n нет поля Base URL?

Это значит, что версия n8n слишком старая. Base URL — параметр дочернего узла OpenAI Chat Model из системы AI-узлов, он есть только в более новых версиях. Сначала обновите n8n до более новой версии, затем выполните шаги настройки Credential, описанные выше.

Ключевые выводы

• Подключение — это изменение одного Credential: в Base URL укажите https://api.hiapi.ai, в API Key — key HiAPI, имя модели вручную — deepseek-v4.1-flash, без написания кода.
• Классификация и подготовка ответа выполняются в одном вызове ИИ со строгим форматом вывода JSON — только так последующее ветвление IF будет работать стабильно.
• Обычные заказы обрабатываются автоматически, жалобы каждый раз эскалируются оператору — эта граница жёстко задаётся ветвлением IF.
• Деньги тратятся по сложности: обычные заказы — на flash, сложные сообщения — на claude-opus-4-8, тот же key, меняется только имя модели.
• Key хранится централизованно в Credential n8n, при 429 — повторная попытка с задержкой, смена модели — изменение в одном месте.