Midjourney API через посредника: надёжность задач, биллинг и миграция (2026)

У Midjourney нет универсального публичного API, и это определяет реальную структуру «посредника» и «прокси»: они не просто меняют домен официального интерфейса, а добавляют слой оркестрации задач и биллинга поверх пула сторонних аккаунтов. Цепочка длиннее, чем у текстового API, и точек отказа больше.

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

Примечание: Midjourney — товарный знак Midjourney, Inc.; остальные названия принадлежат их правообладателям. Статья носит технический характер; автор не связан с Midjourney. Интерфейсы, статусы и биллинг посредников определяются документацией и договором провайдера; статья не является юридической консультацией.

1. Сначала различите четыре вида «посредников»

Тип	Что делает	Основные риски	Для каких задач
Прокси на пуле аккаунтов	Провайдер содержит аккаунты Midjourney и автоматически отправляет задачи	Риск блокировки аккаунтов, очередь, условия сервиса	Небольшие и средние команды, которым нужен API
Агрегирующий шлюз	Единый вход к нескольким моделям изображений	Сопоставление статусов, различия параметров, сбой промежуточного слоя	Задачи с несколькими моделями
Перепродажа/пополнение	Перепродажа подписки или квоты	Стабильность upstream, баланс и возвраты	Небольшие тесты, временные задачи
Собственная автоматизация	Свои аккаунты и скрипты отправки	Эксплуатация, блокировки, вся ответственность	Техническая команда с контролем данных

Что вы покупаете — «техническую услугу» или «квоту модели» — определяет, кто отвечает при сбое. Исходя из этого спрашивайте про договор, счёт и условия обработки данных.

2. Какие звенья добавляются в асинхронную задачу через посредника

Типичная цепочка: ваш сервис отправляет запрос, посредник выполняет аутентификацию, ограничение частоты и списание; сохраняет запись и связывает номер бизнес-заказа с ID задачи upstream; пул аккаунтов ставит задачу в очередь и ждёт генерации; посредник опрашивает или принимает результат и сопоставляет статусы; наконец, сохраняет изображения или передаёт временную ссылку.

Каждый дополнительный переход — ещё одно место, где можно потерять состояние:

Посредник перезапустился или сменил экземпляр, и соответствие задач в памяти потерялось.
Upstream не ответил вовремя, но задача уже создана; посредник вернул ошибку, клиент повторил — получилось два изображения.
Отказ модерации сопоставлен с обычной ошибкой, и бизнес повторяет запрос бесконечно.
Ссылка на результат истекла: задача успешна, но изображение не скачивается.
У webhook нет ключа идемпотентности, и запись попадает в базу дважды.

Оценивая посредника, спрашивайте не только «поддерживает ли Midjourney», но и как сохраняются ID задач, как сопоставляются статусы и как компенсируются сбои.

3. Статусы задач и хранение результатов

Типичные статусы: в очереди, генерация, успех, ошибка, отказ модерации, тайм-аут или истечение. Названия не важны; важно сопоставление: бизнес должен различать «можно повторить» и «повторять бесполезно».

Отказ модерации, ошибку параметров и недостаток баланса не следует повторять автоматически; тайм-ауты и 5xx можно повторять с задержкой; успех с неудачным скачиванием требует отдельной компенсации. У каждой задачи должен быть ключ идемпотентности, чтобы избежать повторного списания и дублирования изображений.

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

4. Как проверять прозрачность биллинга

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

Единица оплаты — задача, успешное изображение или доля подписки.
Оплачиваются ли апскейл и варианты отдельно.
Как тарифицируются ошибки, тайм-ауты, отмена и отказ модерации.
Считаются ли повторные отправки и повторы, есть ли дедупликация по идемпотентности.
Есть ли минимальный платёж, порог предоплаты, правила возврата и тип счёта.
Содержит ли детализация ID задачи, тип действия, статус и сумму списания.

Не ориентируйтесь только на скидку с рекламной страницы. Прогоните 20–50 реальных задач за неделю и сверьте число успешных изображений, задач и счёт. При расхождении требуйте детализацию по ID задач, а не только итоговую сумму. Стоимость других моделей смотрите на странице тарифов; цены меняются вслед за upstream.

5. Ключи, аккаунты и риски upstream

Посредник означает, что промпты, референсные изображения и результаты проходят через третью сторону. Как минимум уточните:

Сохраняются ли промпты и изображения, как долго, используются ли для обучения или улучшения сервиса.
Можно ли ограничить ключ квотой, IP и сроком действия, как заблокировать его при утечке.
Upstream — один пул аккаунтов или несколько каналов, как переключаются при блокировке.
Разрешают ли условия автоматический доступ и перепродажу, где проходит граница ответственности.
Кто отвечает за апелляцию и возврат при споре о модерации контента.

Production-ключ не должен попадать во фронтенд, публичный репозиторий или журналы. Для особо чувствительных материалов выбирайте провайдера с отказом от сохранения данных и возможностью подписать соглашение; если это не подтверждено, сначала маскируйте данные.

6. Условия провайдера и границы ответственности

Посредник может продавать «техническую услугу» или «квоту модели», и ответственность различается. Технический провайдер отвечает за доступность, потерю задач и время реакции; перепродавец квоты часто может обещать лишь «передачу по возможности», и при изменении upstream исправить ситуацию трудно.

В договоре стоит зафиксировать: уровень сервиса и уведомления о сбоях, компенсацию за неудачные задачи, предварительное уведомление об изменении правил upstream, обязанности по обработке и удалению данных, выгрузку данных и судьбу баланса при прекращении сотрудничества. Не соглашайтесь на долгосрочную работу только с перепиской и без стороны договора.

7. Шаги миграции с прямого подключения или собственного решения

Опишите текущие вызовы: модели, параметры, параллельность, среднее время генерации и типы ошибок.
Уточните пути, аутентификацию и различия полей у посредника, составьте таблицу соответствия.
Прогоните в тестовой среде четыре пути: отправка, запрос статуса, отмена и скачивание.
Проведите теневой запуск на одной партии промптов: старая цепочка и посредник работают параллельно, сравнение без переключения.
Сравните долю успеха, время в очереди, задержку P95, доступность изображений и стоимость одного пригодного результата.
Переключайте 5–20% трафика, сохраняя переключатель отката на старую цепочку.
Наблюдайте три-семь дней и проверьте сходимость счетов, детализации задач и бизнес-номеров.
После полного перехода оставьте двухканальную страховку и упрощайте архитектуру только после стабилизации.

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

8. Как проверить посредника

# Отправьте минимальную задачу и запишите task_id и время; пути и поля уточняйте в документации
curl -sS -X POST "$RELAY_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"кот зевает у окна, естественный свет","async":true}'

# Опрашивайте статус и фиксируйте полный переход
curl -sS "$RELAY_BASE_URL/v1/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

При тестировании создавайте исключения: отмените задачу сразу после отправки, передайте неверный параметр, отправьте несколько задач одновременно, прервите скачивание. Проверьте, согласуются ли статусы, сообщения об ошибках и счёт. Затем откройте ссылку результата через 24 часа и проверьте запись задачи через семь дней. Только после этих трёх проверок стоит переходить к постепенному запуску.

9. Мониторинг и откат после миграции

Считайте задачи по статусам, отдельно отслеживайте долю ошибок, отказов модерации, тайм-аутов и отмен.
Фиксируйте время в очереди и время генерации отдельно, чтобы понять, где узкое место — в пуле аккаунтов или upstream.
Следите за долей успешных скачиваний; неудачные задачи отправляйте в очередь компенсации.
Учитывайте 401, 404, 429, 5xx, различая ключ, параметры, лимиты и сбой upstream.
Считайте стоимость «на одну успешно созданную задачу», а не только цену одного вызова.
Задайте порог отката: например, если доля успеха два часа подряд заметно ниже базовой, вернуться на старую цепочку.

Частые вопросы

Чем посредник отличается от прямой подписки Midjourney?

Прямая подписка — официальный продукт для ручной работы; посредник — API-обёртка для автоматизации. Параметры, параллельность и видимость задач могут различаться, а посредник дополнительно несёт риски пула аккаунтов и условий сервиса.

Сохраняет ли посредник мои промпты и изображения?

У разных сервисов по-разному. Уточните, сохраняются ли данные, как долго, где, кто имеет доступ, используются ли они для обучения и как работает удаление. Для клиентских материалов выбирайте провайдера с понятными условиями.

Что делать, если задача потерялась на стороне посредника?

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

Почему счёт не совпадает с числом изображений?

Частые причины — повторные отправки, повторы после ошибок, отдельная оплата апскейла и вариантов, разные правила отказа модерации, минимальный платёж или истёкший баланс. Требуйте детализацию по ID задач и сверяйте построчно.

Нужно ли менять код при миграции?

Если посредник совместим с текущим интерфейсом, обычно достаточно изменить Base URL, ключ и несколько полей. Если отличаются сопоставление статусов или формат callback, придётся менять опрос и запись в базу. Теневой запуск заранее выявит большинство различий.

Что дальше

Создайте тестовый ключ в ZSQH AI Gateway, проверьте минимальной задачей четыре звена — отправку, опрос, скачивание и сверку, — затем переходите к постепенной миграции. Доступные модели и расходы смотрите на странице тарифов; цены могут меняться.