Genius-bot · 11 минут чтения
Если задача звучит как «как подключить api нейросети», необязательно сразу писать отдельное приложение. Для многих сценариев достаточно конструктора автоматизаций с HTTP-узлом: в него передаются URL, метод, заголовок авторизации и параметры запроса. Такой подход позволяет собрать цепочку из готовых блоков, а код оставить только для тех мест, где конструктор уже не справляется.
В этой статье разберём практический вариант интеграции: текст или данные из таблицы становятся входом, HTTP-запрос запускает операцию, а затем сценарий получает готовый результат. Отдельно посмотрим, где находится ключ, как организовать ожидание асинхронной задачи и почему схема «нейросеть без кода api» всё равно иногда заканчивается задачей для разработчика. Документация и выпуск ключа доступны в разделе API.
Что такое HTTP-запрос глазами конструктора сценариев
В конструкторе сценариев HTTP-запрос — это обычный блок с несколькими полями. Вы указываете адрес, например https://genius-bot.ru/wp-json/genius/v1/generate, выбираете метод POST, добавляете заголовок Authorization и передаёте параметры операции. Никакой отдельной библиотеки для этого шага не требуется.
Авторизация выполняется через заголовок Authorization: Bearer <ключ>. То есть в HTTP-узле обычно получается такая связка: метод POST, URL маршрута /generate, заголовок с ключом и тело запроса с параметрами нужной операции.
У API есть несколько маршрутов, и их удобно воспринимать как последовательные блоки одного сценария. GET /services возвращает список операций и цен, GET /balance показывает остаток, POST /uploads нужен для загрузки файла и получения ссылки, POST /generate запускает операцию, а GET /tasks/{id} позволяет получить состояние и результат задачи.
Это важное отличие от простого запроса, который сразу возвращает готовый файл. Запуск операции и получение результата могут быть двумя разными шагами сценария. Поэтому в конструкторе нужно заранее заложить логику ожидания.
Например, схема для обработки задания может выглядеть так:
- получить текст из формы или таблицы;
- сформировать HTTP POST на
/generate; - сохранить идентификатор созданной задачи;
- проверить задачу через
/tasks/{id}; - после готовности передать результат в следующий блок сценария.
Если требуется файл, перед запуском операции может понадобиться отдельный этап загрузки. Маршрут POST /uploads принимает файл и возвращает ссылку, которую затем можно использовать в операции.
Для первого знакомства полезно сделать не сложную цепочку, а один HTTP-запрос и посмотреть его ответ. Например, через curl можно проверить список доступных операций:
curl -X GET "https://genius-bot.ru/wp-json/genius/v1/services" \
-H "Authorization: Bearer ВАШ_КЛЮЧ"Этот запрос не запускает генерацию. Он обращается к /services, поэтому его удобно использовать как диагностический шаг при настройке авторизации. Если HTTP-узел не работает, сначала стоит проверить именно URL, заголовок Authorization и сам ключ.
Где взять ключ и куда его вставить
Ключ выдаётся после входа в разделе API. Он показывается один раз, поэтому его нужно сохранить в менеджере секретов конструктора или в другом безопасном месте, предусмотренном вашей инфраструктурой.
В самом HTTP-узле ключ передаётся не как отдельный параметр URL, а в заголовке. Поле обычно называется Header или Headers, а значение имеет вид Bearer ВАШ_КЛЮЧ.
Например, логически запрос должен содержать два обязательных элемента:
Authorization: Bearer ВАШ_КЛЮЧ
Content-Type: application/jsonЗначение ключа не стоит вставлять непосредственно в текст каждого блока. Если конструктор поддерживает переменные или учётные данные, лучше хранить секрет там и ссылаться на него из HTTP-узлов. Это особенно важно, если сценарий позже будет копироваться или передаваться другому человеку.
Оплата здесь выполняется за запуск операции: абонентской платы и минимального платежа нет. При выпуске первого ключа на баланс начисляется 50 ₽ для пробного использования. Ограничение частоты составляет не более 60 запросов в минуту на один ключ, поэтому массовый сценарий нужно строить с учётом этого лимита.
Перед запуском конкретной операции полезно получить список через GET /services. Так сценарий не приходится строить на догадках о доступных операциях и их стоимости. В справке перечислены, в частности, операции для изображений, видео, аудио, речи и музыки.
| Операция | Цена за запуск |
|---|---|
| Картинка по описанию (image) | 9 ₽ |
| Изменить фото по описанию (image-edit) | 35 ₽ |
| Оживить фото (photo-video) | 25 ₽ |
| Увеличить качество фото (upscale) | 50 ₽ |
| Видео по описанию (video) | 119 ₽ |
| Создать музыку (music) | 59 ₽ |
| Расшифровка записи (stt) | 10 ₽ |
| Озвучка текста (tts) | 18 ₽ за 1000 знаков |
| Говорящий аватар (avatar) | 120 ₽ |
| Убрать шум (denoise) | 36 ₽ |
Остальные указанные в справке операции также имеют фиксированную стоимость запуска: извлечение звука из видео — 0 ₽, удаление вокала — 45 ₽, звук по описанию — 9 ₽. Эти цены указаны именно за один запуск, а для озвучки текста применяется расчёт за 1000 знаков.
Первый сценарий: текст на входе, файл на выходе
Представим сценарий, в котором пользователь вводит описание, а автоматизация запускает генерацию изображения. Источником текста может быть форма, строка таблицы или другой блок конструктора. После получения текста HTTP-узел отправляет запрос на /generate.
Конкретный JSON зависит от параметров выбранной операции, поэтому не стоит копировать произвольные поля из примеров для другой операции. Правильная последовательность настройки такая: сначала определить нужную операцию, затем посмотреть её параметры в доступной документации и только после этого сформировать тело POST-запроса.
Для проверки самой схемы удобно отделить авторизацию от бизнес-логики. Например, Python-запрос к API можно представить так:
import requests
API_KEY = "ВАШ_КЛЮЧ"
url = "https://genius-bot.ru/wp-json/genius/v1/services"
response = requests.get(
url,
headers={
"Authorization": f"Bearer {API_KEY}"
},
timeout=30,
)
response.raise_for_status()
print(response.json())Этот пример использует только стандартный HTTP-подход: адрес API, Bearer-ключ, запрос и обработка ответа. В конструкторе сценариев те же действия раскладываются по полям HTTP-узла. Поэтому понимание Python здесь полезно не для обязательного программирования, а для проверки того, что именно должен делать визуальный блок.
Если входом является файл, сначала используется POST /uploads. После загрузки сценарий получает ссылку на файл, а затем передаёт её в соответствующую операцию через /generate. Это позволяет строить цепочки, в которых пользователь загружает исходник, а следующий блок запускает обработку.
Например, практический сценарий обработки изображения может состоять из пяти блоков: получить файл, загрузить его, получить ссылку, сформировать задание на изменение изображения и дождаться результата. Визуально это уже напоминает небольшой конвейер, хотя отдельного приложения с сервером для него не требуется.
Есть и другой вариант: вместо отдельных маршрутов использовать совместимый с OpenAI интерфейс. Для чата доступны POST /chat/completions и GET /models в том же формате, что и у OpenAI. В клиентской библиотеке при таком подключении достаточно изменить base_url и ключ.
Для чата в справке указана стоимость 40 ₽ за миллион токенов запроса и 400 ₽ за миллион токенов ответа. Это отдельная модель тарификации от операций, где цена указывается за запуск.
Ожидание результата в конструкторе
Самая частая ошибка в безкодовой интеграции — считать, что после POST на /generate сценарий уже получил готовый результат. API предусматривает отдельный маршрут GET /tasks/{id}, поэтому автоматизации нужно сохранить идентификатор задачи и проверить её состояние.
Простой вариант — добавить паузу и затем повторный HTTP-запрос. Если задача ещё не готова, сценарий снова проверяет её через некоторое время. При готовности цепочка передаёт результат дальше: например, сохраняет ссылку или отправляет её в следующий блок.
Более удобный вариант для длительных операций — webhook. При запуске можно передать параметр callback_url. Когда задача готова, на этот адрес приходит POST, после чего отдельный webhook-блок конструктора продолжает сценарий.
Такой подход особенно удобен, если операция может выполняться заметное время. Вместо постоянного опроса можно запустить задачу, закончить текущий сценарий и дождаться входящего запроса на callback-адрес.
При построении цикла проверки стоит предусмотреть ограничение числа попыток. Например, можно проверять задачу через фиксированные интервалы и после нескольких неудачных проверок переводить строку таблицы в статус ошибки. Это уже не требование API, а практическая защита самого сценария от бесконечного цикла.
Ещё один полезный блок — проверка баланса через GET /balance. Его можно поставить перед массовой обработкой, если сценарий расходует деньги на каждое задание. Тогда автоматизация сможет отдельно обработать ситуацию с недостаточным остатком, вместо того чтобы отправлять десятки запросов подряд.
Таблица как источник заданий
Для многих задач таблица удобнее формы. В одной строке можно хранить исходный текст, тип операции, ссылку на файл, статус и результат. Тогда api нейросети в google таблице превращается не в отдельное приложение, а в последовательность действий над строками.
Например, минимальная структура может быть такой:
| Колонка | Назначение |
|---|---|
| A — prompt | Описание задания |
| B — operation | Выбранная операция |
| C — file | Ссылка или исходный файл, если он нужен |
| D — status | new, processing, done или error |
| E — result | Полученная ссылка или другой результат |
Сценарий запускается по расписанию или другим событием, выбирает строки со статусом new, формирует HTTP-запрос и переводит обработанную строку в processing. После завершения задачи в неё записывается результат и устанавливается статус done.
Для n8n нейросеть в такой схеме фактически является одним из этапов workflow. Отдельный HTTP Request node получает значения из предыдущего блока, подставляет их в URL, заголовки или тело запроса, а следующий узел работает уже с ответом API.
Если в таблице находятся десятки или сотни строк, нужно учитывать лимит в 60 запросов в минуту на ключ. Поэтому не стоит бездумно запускать все строки параллельно. Лучше ограничивать количество одновременно обрабатываемых заданий и явно управлять интервалами.
Табличная схема удобна ещё и тем, что её легко контролировать вручную. Можно изменить текст задания, заменить ссылку на файл, повторно поставить статус new и запустить обработку ещё раз. При этом важно не допускать повторного запуска одной строки, пока предыдущая задача ещё выполняется.
Для небольшой команды это часто оказывается достаточным интерфейсом. Пользователю не нужно открывать API-документацию или разбираться в HTTP: он работает со строками таблицы, а технические детали находятся внутри сценария.
Границы безкодового подхода
Нейросеть без кода api хорошо подключается там, где сценарий можно описать последовательностью независимых блоков: взять данные, сделать HTTP-запрос, дождаться результата, записать ответ. Чем больше появляется исключений, условий и преобразований данных, тем быстрее растёт сложность самого workflow.
Первая граница — сложная обработка ошибок. Если нужно различать несколько типов ответа, повторять запросы с разными параметрами, вести подробный журнал и восстанавливать состояние после частичного сбоя, визуальная схема может стать труднее для поддержки, чем небольшой скрипт.
Вторая граница — нестандартное преобразование файлов. Когда требуется сложная подготовка входных данных, изменение структуры файлов или собственная бизнес-логика вокруг результата, одного HTTP-узла уже недостаточно. Конструктор всё ещё может оставаться частью решения, но отдельный программный блок становится оправданным.
Третья граница — большой поток заданий. Ограничение в 60 запросов в минуту на ключ нужно учитывать независимо от выбранного конструктора. Если автоматизация запускает несколько параллельных веток, суммарное количество запросов также нужно контролировать.
Есть и более простой сигнал: если настройка одного сценария требует большого количества промежуточных переменных, циклов, условий и специальных обходов, стоит сначала описать процесс как обычную программу. Разработчик сможет вынести сложную часть в код, а конструктор оставить для запуска, расписания и передачи данных между системами.
При этом переход к коду не означает отказ от HTTP-интеграции. Те же маршруты остаются основой взаимодействия: /services для получения списка операций, /balance для остатка, /uploads для файлов, /generate для запуска и /tasks/{id} для получения состояния и результата.
Практический критерий здесь простой: если задачу можно выразить несколькими понятными блоками и она не требует сложной обработки ошибок, конструктор подходит. Если правила становятся настолько разветвлёнными, что их сложно проверить глазами, разумнее подключить разработчика и оставить безкодовый слой только там, где он действительно упрощает эксплуатацию.
Частые вопросы
Можно ли подключить API без программирования?
Да. HTTP-узел конструктора сценариев может отправлять запросы к API с нужным URL, методом и заголовком Authorization. Для более сложной логики может понадобиться код, но сам HTTP-вызов не требует написания приложения.
Где получить ключ API?
После входа ключ выдаётся в разделе API. Он показывается один раз, поэтому его следует сохранить в безопасном месте. В запросах ключ передаётся через заголовок Authorization: Bearer <ключ>.
Как получить результат асинхронной задачи?
После запуска через POST /generate можно проверять состояние через GET /tasks/{id}. Другой вариант — передать параметр callback_url и продолжить сценарий после POST-запроса от API на указанный адрес, когда задача будет готова.
Можно ли использовать таблицу как очередь заданий?
Да. В строке можно хранить описание, операцию, файл, статус и результат. Сценарий выбирает строки со статусом new, запускает обработку и после завершения записывает результат обратно.
Есть ли ограничение на количество запросов?
На один ключ допускается не более 60 запросов в минуту. Для массовой обработки это ограничение нужно учитывать при настройке параллельных веток и циклов.
Когда без кода уже недостаточно?
Если появляются сложные преобразования файлов, разветвлённая обработка ошибок, большое количество условий или нестандартная бизнес-логика, проще подключить разработчика. При этом конструктор можно сохранить для расписаний, триггеров и передачи данных, а код использовать только для сложной части.
Для начала достаточно выбрать одну операцию, получить ключ, сделать тестовый HTTP-запрос и проверить полный путь от входных данных до результата. Подробности по доступным маршрутам, ключу и настройке подключения можно посмотреть в документации API.
