Кандинский API и очередь модерации после первого image-запроса

Первый успешный запрос к Кандинскому не возвращает картинку: он возвращает UUID задачи и статус, который затем нужно опрашивать отдельно. Официальная документация FusionBrain описывает генерацию как асинхронный процесс — run-запрос к text2image отдаёт идентификатор задачи, а сам файл появляется только после того, как отдельный status-запрос вернёт значение done. Это меньшая из проблем разработчика image-функции.

Большая проблема начинается там, где заканчивается ответ API. Даже статус done ничего не говорит о судьбе результата: кто принимает картинку в каталог, кто её отклоняет, где она хранится, можно ли использовать её повторно и сколько она стоила бюджету. На эти вопросы Кандинский API не отвечает в принципе, потому что они принадлежат продукту, а не платформе.

Эта статья — операционный разбор того, что происходит после ответа API. Я раскладываю один набор сгенерированных изображений на пять решений и показываю, зачем канбан статусов нужно спроектировать до того, как генерация пойдёт в масштаб. Сразу оговорю границу: сам канбан не подтверждает параметры, лимиты и права доступа, их придётся проверять отдельно, на своих ключах и в актуальной версии соглашения. Условия API сверены на 2026-07-18: квоты и текст соглашения меняются без предупреждения, и это дата фиксации, а не гарантия неизменности.

Подключите модели для проверки контента с оплатой в рублях на provod.ai

Генерация заканчивается не файлом, а решением

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

Если вы строите image-функцию, разумно с самого начала считать генерацию источником сырья, а не готовым каталогом. Здесь уместно назвать альтернативный медиамаршрут внутри того же процесса отбора: у provod.ai есть генерация и редактирование изображений в одном чате рядом с текстовыми моделями каталога, доступного через платформу, и общее командное пространство с единым балансом организации, где решения о судьбе результата остаются в одном месте для всей команды. Смена источника изображений не отменяет очередь решений, она делает её общей для нескольких каналов сразу.

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

Кандинский API возвращает UUID и статус, а не готовое изображение

Начнём с того, что задокументировано и что можно принять как данность. Доступ к Кандинскому (FusionBrain) идёт через api-key.fusionbrain.ai. По официальной документации нужны сразу два значения: Key и Secret, оба выдаются после регистрации на fusionbrain.ai и открытия страницы ключей. Авторизация происходит через два заголовка, X-Key: Key {api_key} и X-Secret: Secret {secret_key}; один без другого не работает.

Второй факт: асинхронность, и он ключевой для всей статьи. Клиент отправляет run-запрос к text2image и получает UUID задачи, а затем отдельно опрашивает status-эндпоинт. Возвращаемый статус: небольшой фиксированный словарь значений (начальный или в очереди, в обработке, готово, ошибка либо сервис отключён). Синхронного ответа «вот картинка» в протоколе не предусмотрено; это подтверждают и открытая интеграция ai-forever/mcp_kandinsky, и сторонний Go-клиент, разбирающий тот же поток запросов.

Параметрическая поверхность при этом стабильна. И официальная документация, и интеграция ai-forever сходятся на одном наборе: prompt, negative prompt, style, width, height, где 1024×1024 — распространённое значение по умолчанию, плюс небольшой фиксированный набор стилей. Если поискать кандинский api в её нынешнем виде, устоявшейся окажется именно эта поверхность параметров: всё, что происходит с результатом дальше, документация не описывает вовсе.

Здесь же честно скажу про расхождение источников. Выдержка официальной документации ссылается на вызов листинга pipelines и models, а репозиторий ai-forever — на text2image/run и text2image/status/{uuid}. Похоже на дрейф версий API во времени, и его нужно сверять с живой документацией, а не додумывать: прямое чтение страниц fusionbrain.ai во время подготовки материала не удалось (соединение отклонялось), поэтому формулировки восстановлены из поисковых выдач и одного независимого юридического разбора. Перед внедрением открой актуальные страницы сам.

Граница между фильтром вендора и твоей модерацией

В ответе status-эндпоинта есть поле censored. Это результат срабатывания собственного автоматического фильтра Кандинского: решение вендора о том, что результат заблокирован или изменён, а не решение твоей команды. Поле подтверждено и интеграцией ai-forever, и Go-клиентом, разбирающим формат ответа. Путать его с продуктовой модерацией легко, а стоит дорого: censored отвечает на вопрос «пропустил ли контент фильтр платформы», а не на вопрос «годится ли картинка в наш продукт».

Смешать эти два решения — значит потерять центральное различие всей задачи. Пройденный фильтр вендора не означает «принято». Картинка может быть безопасной с точки зрения платформы и при этом бесполезной, дублирующей, не попадающей в бренд или юридически рискованной по твоим меркам. Именно поэтому продуктовая очередь начинается там, где заканчивается censored: в неё попадают только результаты со статусом done, не заблокированные фильтром, и уже их разбирает команда.

Путаница заметна даже в переписке команд про инциденты: где-то мелькнёт формулировка «api кандинский заблокировал результат», хотя на самом деле сработал не продукт, а фильтр вендора внутри платформы. Именно такую путаницу должен закрывать канбан, а не сам API.

Пять статусов: как разметить один набор результатов?

Дальше: метод, который предлагаю я сам и за который отвечаю сам, никакой источник его не диктует. Берётся один набор сгенерированных изображений, и каждый результат раскладывается в один из пяти статусов: принять, отклонить, доработать, сохранить, повторно использовать. Это и есть предлагаемый канбан «результат — модерация — повтор — архив — расход».

Гипотеза здесь честно обозначена как гипотеза: что любой набор результатов можно однозначно разложить в один из пяти статусов. Дневник разработки её проверяет, а не декларирует. Если картинка не ложится ни в один статус, например непонятно, дорабатывать её или отклонять, значит определение статуса дырявое, и чинить его нужно до того, как генерация пойдёт в масштаб.

• Принять: результат идёт в продукт как есть. Триггер: прошёл censored, попал в бренд, решает задачу промпта.
• Отклонить: результат выбрасывается. Триггер: заблокирован фильтром, вне бренда или бесполезен; важно зафиксировать сам факт расхода, даже если картинка не используется.
• Доработать: результат перегенерируется с изменённым prompt, negative prompt или размером. Триггер: идея верная, исполнение нет.
• Сохранить: результат уходит в архив без немедленного использования. Триггер: может пригодиться позже, права позволяют хранение.
• Повторно использовать: ранее сохранённый результат достаётся вместо новой генерации. Триггер: экономит расход и лимит.

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

Что говорят про права, и почему API их не решает?

Здесь важно не нарушить доменное исключение: права нельзя выводить из самого результата. По официальному пользовательскому соглашению Кандинского исключительное право на сгенерированное изображение принадлежит пользователю с момента генерации — и та же оговорка одновременно обязывает пользователя выдать оператору платформы бесплатную, неисключительную, всемирную, бессрочную лицензию воспроизводить, распространять, публично показывать и изменять то же изображение. Ты владеешь результатом, но платформа в тот же момент получает на него широкую лицензию. Ту же клаузу подтверждает и независимый юридический разбор на vc.ru.

Соглашение запрещает приписывать создание изображения администрации или правообладателям и использовать товарные знаки платформы, но разрешает, не требует, подпись вроде «создано при помощи нейросети Kandinsky». Отдельно оно снимает с себя гарантии: не гарантирует, что изображение уникально или оригинально, и не гарантирует, что его использование не нарушит чужую интеллектуальную собственность. Этот юридический риск берёт на себя пользователь, и ответ API его не закрывает никак.

Практический вывод для канбана: статусы «сохранить» и «повторно использовать» нельзя ставить, опираясь на саму картинку. Их можно ставить только сверившись с актуальной версией соглашения, потому что такие документы правятся в одностороннем порядке. На дату 2026-07-18 формулировки такие, к моменту публикации переоткрой связывающую версию, а не считай её неизменной.

Сколько это стоит и почему лимиты тоже статус?

Лимиты меняются, и это не абстракция. По отчёту CNews за 2025 год бесплатный тариф веб-платформы fusionbrain.ai урезали до 20 генераций в месяц (раньше после регистрации было фактически без ограничений), а платные планы ввели: около 499 рублей в месяц за 200 изображений. Важная оговорка: эти цифры описывают квоту веб-интерфейса и не подтверждены как идентичные лимитам API-ключа — лимиты своих ключей нужно проверять отдельно, на своей странице аккаунта.

Почему это часть канбана, а не отдельная тема. Каждый статус тратит либо лимит, либо деньги, либо и то и другое. «Отклонить»: уже потраченная генерация, которую ты не используешь. «Доработать»: ещё одна генерация поверх первой. «Повторно использовать»: единственный статус, который лимит экономит. Если расход не привязан к статусу, о выработанной квоте узнаёшь постфактум, когда очередь уже забита нерешёнными результатами.

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

Модерация не зависит от источника изображения

Когда каналов и моделей становится больше одного, стоит держать в голове: очередь отбора не привязана к конкретному API. Кандинский даёт российскую генерацию, свой фильтр и своё соглашение, но саму продуктовую модерацию платформа за тебя не делает — это остаётся задачей команды при любом провайдере. Если результат приходит из другого канала с другим протоколом интеграции, статусы «принять», «отклонить», «доработать», «сохранить», «повторно использовать» всё равно применяются к нему ровно так же, потому что модерация — решение продукта, а не свойство конкретного API.

Чего этот канбан не решает

Честные ограничения, без которых разбор превращается в рекламу метода.

• Канбан не подтверждает endpoint, авторизацию, параметры, лимиты и права: всё это проверяется отдельно, на живой документации и на твоих ключах.
• Статусы не гарантируют, что набор всегда разложится однозначно: это гипотеза, которую проверяет разметка первого набора, а не установленный факт.
• Флаг censored — фильтр вендора, а не продуктовый вердикт команды; он сужает вход в очередь, но не заменяет решение.
• Права нельзя вывести из результата: соглашение правится в одностороннем порядке, поэтому связывающую версию нужно переоткрывать перед внедрением.
• Квоты веб-интерфейса из отчёта 2025 года подтверждают, что лимиты меняются, а не то, что лимит API-ключа зафиксирован навсегда.

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

Решение

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

Следующий конкретный шаг — разметить один реальный набор генераций по пяти статусам и проверить, ложится ли каждый результат однозначно. Не ложится: чини определения статусов, прежде чем включать поток на полную мощность. И перед внедрением переоткрой живую документацию FusionBrain и актуальную версию соглашения: параметры, лимиты и права на дату 2026-07-18 требуют отдельной проверки именно на твоих ключах.

FAQ

Что возвращает Кандинский API на первый запрос?

UUID задачи, а не картинку. По документации FusionBrain генерация асинхронная: run-запрос отдаёт идентификатор, а статус опрашивается отдельно и принимает одно из значений фиксированного словаря вплоть до done или failed.

Чем censored отличается от продуктовой модерации?

censored — это срабатывание фильтра самого Кандинского, решение вендора. Продуктовая модерация решает, годится ли пропущенный фильтром результат в продукт. Это два разных вопроса, и второй API не закрывает.

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

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

Сколько стоит доступ?

По отчёту CNews за 2025 год бесплатный веб-тариф ограничили 20 генерациями в месяц, платный стоит около 499 рублей за 200 изображений. Это квота веб-интерфейса: для серверной интеграции через кандинский апи лимиты ключа стоит проверять отдельно от квот сайта.

Можно ли автоматически принимать все done-результаты?

Нет. Статус done говорит только, что модель отработала. Разметка на пять статусов, принять, отклонить, доработать, сохранить, повторно использовать, остаётся ручным или полуручным решением с назначенным владельцем.

provod.ai — единая точка для retrieval и генерации

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Единая точка доступа не скрывает экономику компонентов: стоимость каждого вызова соответствует официальному тарифу 1:1, без маржи provod.ai.

Соберите RAG на едином балансе: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции

Источники

• Официальная документация FusionBrain (Кандинский), доступ 2026-07-18: аутентификация, асинхронный run/poll, параметры.
• Пользовательское соглашение fusionbrain.ai, доступ 2026-07-18: права, лицензия, дисклеймеры.
• Юридический разбор сервиса FusionBrain на vc.ru, доступ 2026-07-18: те же клаузы прав.
• Репозиторий ai-forever/mcp_kandinsky, GitHub, доступ 2026-07-18: флаг censored, параметры.
• go-fusionbrain-api, pkg.go.dev, доступ 2026-07-18: словарь статусов, censored.
• CNews, отчёт 2025 года, доступ 2026-07-18: изменение квот и цен веб-тарифа.