Genius-bot · 12 минут чтения
Если в магазине сотни или тысячи SKU, api генерации картинок удобнее рассматривать не как отдельный редактор, а как часть конвейера: на вход поступает исходное фото и параметры товара, на выходе — подготовленная серия изображений. Такой подход позволяет заранее задать фон, свет, композицию и набор ракурсов, а затем повторять процесс для каждой позиции. Раздел с доступом к API находится здесь: получить ключ и открыть API.
Для карточек особенно полезна связка операций «Изменить фото по описанию» за 35 ₽ и «Картинка по описанию» за 9 ₽. Первая подходит, когда нужно работать с исходником товара, вторая — когда изображение можно создавать по текстовому описанию без исходной фотографии. В обоих случаях стоимость считается за запуск операции, поэтому бюджет можно рассчитать до запуска массовой обработки.
Ниже — практический сценарий для интернет-магазина: один визуальный стандарт, несколько ракурсов каждого товара, подготовка размеров и автоматическая проверка перед выгрузкой. Отдельно разберём, как организовать фото товара нейросеть api и посчитать стоимость серии из тысячи карточек.
Что требуют площадки от фотографий товара
Первое правило конвейера — не начинать с генерации, пока не определён формат результата. У разных площадок могут отличаться требования к размеру изображения, соотношению сторон, допустимому фону и содержанию кадра. Поэтому параметры конкретной площадки лучше вынести в конфигурацию магазина, а не зашивать в текстовое описание каждого товара.
Для каждого SKU удобно хранить как минимум четыре поля: идентификатор товара, исходное изображение, описание визуального стиля и набор требуемых ракурсов. Например, для одной позиции можно задать серию из пяти кадров: фронтальный вид, вид под углом 45 градусов, задняя сторона, крупная деталь и общий кадр в контексте использования.
Здесь важно разделить генерацию и техническую подготовку. API отвечает за запуск операции и получение результата, а ваш скрипт может отдельно проверять разрешение, формат файла, соотношение сторон и наличие результата перед публикацией. Если изображение не прошло проверку, SKU не отправляется дальше по конвейеру.
При массовой обработке имеет значение и ограничение частоты. Для одного ключа допускается не больше 60 запросов в минуту, поэтому тысячу операций нельзя просто отправить одним плотным циклом без учёта ответа API. Практическая схема — очередь задач, ограничитель скорости и повторная проверка статуса через GET /tasks/{id}.
Авторизация выполняется через заголовок Authorization: Bearer <ключ>. Ключ выдаётся после входа в разделе API и показывается один раз, поэтому в рабочем скрипте его лучше хранить в переменной окружения, а не прописывать непосредственно в коде.
Единый стиль для всей витрины: заготовка описания
Генерация картинок для товаров начинает давать предсказуемый результат, когда описание строится по шаблону. Вместо уникального промпта для каждого SKU можно разделить его на постоянную часть и переменные поля. Постоянная часть отвечает за визуальный язык магазина, переменная — за конкретный товар и нужный ракурс.
Например, постоянную часть можно сформулировать так: «предметная фотография товара, нейтральный светлый фон, мягкий рассеянный свет, одинаковая высота камеры, реалистичные материалы, товар полностью в кадре, без декоративных надписей и логотипов, единый стиль каталога». Затем к ней добавляется описание самого товара и конкретного ракурса.
Для каждого SKU можно хранить шаблон примерно такого вида:
{
"product": "керамическая кружка, матовая поверхность, синяя ручка",
"style": "предметная фотография, светлый нейтральный фон, мягкий рассеянный свет",
"angle": "фронтальный вид, ручка полностью видна",
"composition": "товар по центру, без обрезания краёв"
}Такой формат удобен не только для человека, который готовит контент. Его можно собрать программно из CSV, базы товаров или внутреннего каталога, а затем передавать готовое описание в POST /generate. Если описание для тысячи товаров формируется автоматически, единый шаблон снижает количество ручных правок перед запуском.
В API сначала полезно запросить GET /services и получить список доступных операций и цен. Для сценария с исходными фотографиями понадобится операция image-edit, а для создания изображения без исходника — image. После запуска POST /generate возвращает идентификатор задачи, который затем используется для проверки через GET /tasks/{id}.
Минимальный запрос через curl выглядит так:
curl -X POST "https://genius-bot.ru/wp-json/genius/v1/generate" \
-H "Authorization: Bearer $GENIUS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"service": "image",
"prompt": "Предметная фотография керамической кружки, светлый нейтральный фон, мягкий рассеянный свет, фронтальный вид, товар полностью в кадре"
}'Для рабочего проекта названия параметров конкретной операции следует брать из ответа GET /services и документации API, а не переносить этот минимальный пример вслепую на все операции. Сам принцип конвейера остаётся тем же: получить описание операции, отправить задачу, сохранить её ID и дождаться результата.
Серия ракурсов одного товара
Одна из главных задач каталога — не просто получить красивый кадр, а сделать несколько изображений одного и того же товара. Здесь важно отделить неизменяемые свойства объекта от переменного ракурса. Цвет, форма, материал и конструктивные детали должны описываться одинаково во всех запросах, а положение камеры меняется отдельным полем.
Например, для товара «чёрная настольная лампа» можно создать пять заданий с одной базой описания. В первом указать фронтальный вид, во втором — угол 45 градусов, в третьем — вид сзади, в четвёртом — крупный план переключателя, в пятом — общий кадр с небольшим пространством вокруг товара.
Это особенно полезно, когда картинки для маркетплейса должны показывать не только внешний вид, но и детали, которые покупателю сложно оценить по одному кадру. При этом для серии лучше не менять одновременно свет, фон и композицию. Иначе после генерации придётся вручную приводить кадры к единому виду.
Для каталога из 1000 товаров такая схема означает 5000 запусков, если на каждый SKU приходится пять изображений. При цене 9 ₽ за операцию image теоретическая стоимость генерации составит 45 000 ₽. Если вместо создания с нуля используется image-edit, то при тех же пяти кадрах стоимость будет 175 000 ₽, без учёта дополнительных операций.
У операций разная цена, поэтому архитектура конвейера напрямую влияет на смету. Например, upscale стоит 50 ₽ за запуск. Его не обязательно применять ко всем изображениям: разумнее включать такую операцию только в ветку, где исходный или полученный файл не соответствует требуемому качеству.
Для контроля серии удобно хранить статус каждого кадра отдельно. Пример структуры записи в собственной базе может выглядеть так:
{
"sku": "LAM-1000",
"angle": "front",
"task_id": "12345",
"status": "processing",
"result_url": null
}Когда GET /tasks/{id} показывает готовый результат, запись переводится в состояние completed. Вместо постоянного опроса можно использовать необязательный callback_url: после готовности задачи API отправит POST на указанный адрес.
Размеры и обрезка под разные площадки
Размер изображения лучше считать параметром публикации, а не свойством конкретного товара. Один и тот же исходный кадр может понадобиться для основной карточки, дополнительной галереи и другого канала продаж, где используется иной размер или соотношение сторон.
Внутри конвейера удобно разделить два этапа: сначала получить мастер-изображение, затем подготовить производные варианты. Например, генерация создаёт исходный кадр, после чего отдельный модуль проверяет ширину и высоту, определяет нужную обрезку и формирует файл под конкретную площадку.
Если исходник слишком мал, можно передать его в операцию upscale за 50 ₽. Но применять её автоматически к каждой фотографии при большом каталоге стоит только после проверки реальной необходимости: при тысяче товаров дополнительный запуск для каждого изображения добавит 50 000 ₽ к расходам.
Полезно также хранить размеры в конфигурации, а не в промпте. Например:
{
"channel": "marketplace_a",
"width": 1200,
"height": 1200,
"crop": "center"
}Тогда один результат можно последовательно проверить по нескольким профилям публикации. Сам API генерации картинок в такой архитектуре отвечает за содержимое изображения, а правила конкретных каналов остаются в вашем коде обработки.
Если нужно сделать тысячу карточек, заранее стоит оценить количество именно API-запусков, а не количество товаров. Один товар с пятью ракурсами и одним дополнительным upscale — это уже шесть запусков. При массовой обработке эта разница быстро превращается в заметную часть бюджета.
Проверка перед выгрузкой: что отсеивать
Автоматический конвейер не должен считать задачу успешной только потому, что API вернул готовый файл. Перед публикацией полезно ввести отдельный этап контроля. Он может отсеивать изображения с неправильными техническими параметрами и отправлять сомнительные результаты на ручную проверку.
Первый набор проверок — технический: файл существует, открывается, имеет нужное разрешение и соответствует профилю площадки. Второй — содержательный: товар полностью помещается в кадр, нужный ракурс присутствует, фон соответствует шаблону, а ключевые детали товара не потерялись.
Особенно важна проверка серии, а не только отдельных изображений. Если на одном из пяти кадров поменялся цвет корпуса или исчезла характерная деталь, такой файл лучше остановить до публикации, даже если остальные четыре изображения выглядят корректно.
Для автоматизации удобно использовать статусы:
| Статус | Действие |
|---|---|
| queued | Задание стоит в очереди |
| processing | Проверять GET /tasks/{id} или ждать callback_url |
| completed | Проверить файл и параметры публикации |
| rejected | Не передавать изображение в выгрузку |
Такой контроль также защищает от повторного списания. Если задача уже завершилась успешно, её результат можно сохранить и не запускать операцию повторно только из-за повторного запуска скрипта. Для массового процесса это особенно важно: идентификатор SKU и ракурса должен однозначно связываться с конкретной задачей.
Ещё один практический момент — баланс. GET /balance позволяет проверить остаток перед запуском очереди. Если средств недостаточно, скрипт может остановить постановку новых задач до пополнения, вместо того чтобы отправлять сотни запросов, которые не будут обработаны.
Смета на тысячу карточек
Стоимость зависит прежде всего от того, сколько изображений создаётся на один товар и используется ли исходная фотография. Базовые цены операций, которые относятся непосредственно к изображениям, выглядят так:
| Операция | Цена за запуск | Пример применения |
|---|---|---|
| Картинка по описанию (image) | 9 ₽ | Создание кадра по текстовому описанию |
| Изменить фото по описанию (image-edit) | 35 ₽ | Работа с исходным фото товара |
| Увеличить качество фото (upscale) | 50 ₽ | Дополнительное повышение качества |
| Оживить фото (photo-video) | 25 ₽ | Создание анимированной версии |
| Видео по описанию (video) | 119 ₽ | Отдельный видеоматериал |
Цены указаны в рублях за один запуск. Для задачи из тысячи товаров, где нужен один сгенерированный кадр на SKU, операция image даст 1000 × 9 ₽ = 9000 ₽. Если требуется пять ракурсов на каждый товар, получится 5000 запусков и 45 000 ₽.
Для сценария с исходными фотографиями расчёт другой. Тысяча товаров с одним изменённым кадром на каждый SKU через image-edit — это 1000 × 35 ₽ = 35 000 ₽. Пять кадров на товар — 5000 × 35 ₽ = 175 000 ₽.
Добавление upscale ко всем пяти тысячам кадров увеличит смету ещё на 250 000 ₽. Поэтому перед массовым запуском полезно определить правило, по которому эта операция включается только для файлов, действительно не проходящих техническую проверку.
Есть и ограничение по скорости. При максимуме 60 запросов в минуту один ключ теоретически может отправить до 3600 запросов за час, если все запросы укладываются в установленный лимит и система отвечает без дополнительных задержек. Для 5000 запусков одного ракурса на 1000 товаров это означает, что очередь нельзя проектировать как мгновенную отправку всех запросов; нужен контролируемый поток.
На практике я бы разделил конвейер на четыре независимых этапа: подготовка данных SKU, отправка задач, ожидание результатов и финальная проверка. Это позволяет повторить только сломавшийся этап. Например, если файл уже сгенерирован, но не прошёл проверку размера, нет необходимости заново создавать изображение.
Python-скрипт для запуска задачи можно построить на requests:
import os
import requests
API_KEY = os.environ["GENIUS_API_KEY"]
BASE_URL = "https://genius-bot.ru/wp-json/genius/v1"
payload = {
"service": "image",
"prompt": (
"Предметная фотография товара, "
"светлый нейтральный фон, мягкий рассеянный свет, "
"товар полностью в кадре, ракурс 45 градусов"
)
}
response = requests.post(
f"{BASE_URL}/generate",
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
json=payload,
timeout=60,
)
response.raise_for_status()
task = response.json()
print(task)Для полноценной очереди вокруг этого запроса добавляются ограничитель частоты, сохранение task ID и обработчик GET /tasks/{id}. Если используется webhook, вместо постоянного опроса можно принять POST на свой callback_url и продолжить обработку после уведомления о готовности.
Отдельно стоит учитывать стартовый баланс: при выпуске первого ключа на баланс начисляется 50 ₽ для пробы. Оплата идёт за запуск, без абонентской платы и без минимального платежа. Это позволяет сначала проверить один шаблон на небольшом количестве SKU, а уже после проверки считать массовую очередь.
Таким образом, для тысячи карточек смета считается простой формулой: количество товаров × количество кадров на товар × цена операции, после чего отдельно добавляются только те дополнительные операции, которые реально понадобились. Например, 1000 товаров × 5 кадров × 9 ₽ = 45 000 ₽ для image, а 1000 товаров × 1 кадр × 35 ₽ = 35 000 ₽ для image-edit.
Ключевая идея конвейера — не пытаться решить все задачи одним запросом. Шаблон стиля отвечает за единообразие, параметры ракурса — за серию, профиль площадки — за размеры, а проверка перед выгрузкой — за отсев проблемных файлов. В результате фото товара нейросеть api становится обычным этапом обработки каталога, который можно измерить в количестве запусков, времени очереди и рублях.
Частые вопросы
Сколько стоит сделать одну картинку товара через API?
Операция «Картинка по описанию» стоит 9 ₽ за запуск. Если требуется изменить существующую фотографию по описанию, операция image-edit стоит 35 ₽ за запуск.
Можно ли сделать несколько ракурсов одного товара?
Да, конвейер можно построить как серию отдельных задач: для каждого ракурса формируется своё описание и запускается отдельная операция. Стоимость серии считается по числу запусков.
Как получить результат задачи?
После запуска сохраняется идентификатор задачи. Состояние и результат можно получать через GET /tasks/{id}; также предусмотрен необязательный callback_url, на который приходит POST после готовности задачи.
Что делать, если фотографии нужны в большом количестве?
Нужно учитывать ограничение не более 60 запросов в минуту на один ключ и строить очередь с контролем скорости. Для тысячи товаров особенно важно хранить ID задач и не создавать повторно уже успешно обработанные позиции.
Нужно ли загружать исходное фото товара?
Это зависит от сценария. Для работы с исходным изображением предусмотрена операция image-edit, а для создания картинки по текстовому описанию — image. В API также есть POST /uploads для загрузки файла и получения ссылки.
Где взять ключ API и посмотреть доступные операции?
Ключ выдаётся после входа в разделе API и показывается один раз. Актуальные сведения об операциях и ценах можно получить через GET /services, а сам доступ к разделу находится здесь: страница API и ключа.
