Midjourney API Relay and Proxy: Task Reliability, Billing, Migration (2026)

Midjourney has no public general-purpose API, and that determines the real structure of a "relay" or "proxy": it is not the official interface under a different domain, but an additional layer of task orchestration and billing on top of a third-party account pool. The chain is longer than a text API, and there are more places for errors to occur.

This article starts from the actual chain and explains task states, result retention, billing reconciliation, key and account risks, provider terms, and migration and acceptance.

Note: Midjourney is a trademark of Midjourney, Inc., and other product names mentioned are trademarks of their respective owners. This article is a technical explanation only; it has no affiliation or partnership with Midjourney. The interfaces, states, and billing of relay services are governed by the provider's documentation and contract, and this article does not constitute legal advice.

1. Distinguish four kinds of "relay"

Type	What it does	Main risk	Suitable scenario
Account-pool proxy	The provider maintains Midjourney accounts and submits automatically	Account controls, queuing, terms risk	Small and mid-sized teams that need an API shape
Aggregation gateway	A unified entry point connected to several image models	State mapping, parameter differences, middle-layer failures	Multi-model operations
Resale or top-up	Resells subscriptions or credits	Upstream stability, balance, and refunds	Small trials and temporary needs
Self-built automation	You maintain the accounts and submission scripts	Operations, bans, all responsibility on you	Technical teams that need data control

Whether you are buying "technical service" or "model credits" determines who is responsible when something goes wrong. Ask about contracts, invoices, and data terms with that distinction in mind.

2. What async tasks add to a relay chain

A typical chain looks like this: your service submits a request; the relay handles authentication, rate limiting, and charging; the relay persists a mapping between the business order number and the upstream task ID; the account pool queues and submits the job; the relay polls or receives the result and maps the state; finally, it stores the image or passes through a temporary link.

Every additional hop is another place where state can be lost:

The relay restarts or changes instances, and in-memory task mappings disappear.
The upstream times out but the task was created; the relay returns a failure, the caller retries, and two sets of images are produced.
A moderation rejection is mapped to a generic failure, and the business retries repeatedly.
The result link expires, so the task shows success but the image download fails.
A webhook has no idempotency key, so the business inserts the same record twice.

When evaluating a relay, do not only ask "does it support Midjourney?" Ask how task IDs are persisted, how states are mapped, and how failures are compensated.

3. Task states and result retention

Common states include queued, generating, succeeded, failed, moderation rejected, timed out, and expired. The names do not matter; the mapping does. The business side must be able to distinguish "can retry" from "retrying is useless."

Moderation rejections, parameter errors, and insufficient balance should not be retried automatically. Timeouts and 5xx responses can be retried with backoff. A success whose download failed needs a separate compensation path. Every task needs an idempotency key to avoid duplicate charges and duplicate images.

Ask four questions about result retention: how long task records are kept; whether images are stored on your behalf and where; whether the response is a temporary link or a long-term address; and whether the task can still be queried by business order number after expiry. Image links usually expire, so download and persist them immediately after a successful generation.

4. How to verify billing transparency

Image task billing is more prone to disputes because one request may include imagine, upscale, variations, and retries. Before signing, confirm:

Whether the billing unit is a task, a successfully delivered image, or a subscription credit conversion.
Whether upscales and variations are billed separately.
Whether failures, timeouts, cancellations, and moderation rejections are billed.
Whether duplicate submissions and retries are charged again, and whether idempotent deduplication exists.
Whether there is a minimum spend, prepayment threshold, refund policy, and invoice type.
Whether usage details include task ID, action type, status, and charged amount.

Do not rely on the discount advertised on the landing page. Run 20 to 50 real tasks for a week and reconcile the number of successful images, the number of tasks, and the invoice. If there is a gap, ask for a per-task-ID charge breakdown, not just a total. Costs for other models on the site are subject to model pricing, and prices change with upstream adjustments.

5. Keys, accounts, and upstream risk

A relay means prompts, reference images, and generated images all pass through a third party. Confirm at least:

Whether prompts and images are stored, for how long, and whether they are used for training or service improvement.
Whether keys can be limited by quota, IP, and expiry, and how they are revoked after a leak.
Whether the upstream is a single account pool or multiple channels, and how traffic switches when an account is banned.
Whether the terms allow automated access and resale, and how responsibility is divided.
Who handles appeals and refunds when a moderation dispute occurs.

Do not put production keys in front-end code, public repositories, or logs. For highly sensitive material, prefer providers that support no-persistence processing and will sign a data agreement; if that cannot be confirmed, redact before uploading.

6. Provider terms and responsibility boundaries

A relay may sell "technical service" or "model credits," and the responsibilities differ. A technical service provider should be responsible for availability, lost tasks, and response times; a credit reseller can often only promise "best-effort forwarding," and once the upstream changes, remedies are limited.

The contract should specify: service levels and incident notification, compensation for failed tasks, advance notice of upstream rule changes, data processing and deletion obligations, and data export and balance handling after termination. Do not accept a long-term arrangement with only chat records and no contracting entity.

7. Steps to migrate from direct access or self-built automation to a relay

Inventory current calls: models, parameters, concurrency, average generation time, and failure types.
Confirm the relay's endpoint paths, authentication method, and field differences, and write a mapping table.
Exercise four paths in a test environment: submit, query, cancel, and download.
Run shadow traffic with the same prompts, one copy through the original chain and one through the relay, comparing without switching.
Compare success rate, queue time, P95 latency, image download rate, and cost per usable image.
Shift traffic gradually at 5% to 20%, keeping a switch to fall back to the original chain.
Observe for three to seven days and confirm that invoices, task details, and business order numbers reconcile.
After full cutover, keep dual channels for a period and simplify the architecture only after stability is confirmed.

During migration, do not delete the original account or old keys, and do not write both sets of tasks under the same business order number, or reconciliation will be impossible.

8. How to validate a relay

# Submit a minimal task and record task_id and submission time; paths and fields depend on provider docs
curl -sS -X POST "$RELAY_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"a cat yawning by a window, natural light","async":true}'

# Poll the status and record the full transition
curl -sS "$RELAY_BASE_URL/v1/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Introduce failures during testing: cancel immediately after submission, send wrong parameters, submit concurrently, and interrupt a download. Check whether states, error messages, and billing agree. Then access the result URL after 24 hours and query the task record after seven days. Only a relay that passes these three checks is worth a gradual rollout.

9. Monitoring and rollback after migration

Count tasks by state, focusing on the share of failed, moderation-rejected, timed-out, and cancelled tasks.
Record queue time and generation time separately to locate bottlenecks in the account pool or upstream.
Monitor the image download success rate and move failed tasks into a compensation queue.
Count 401, 404, 429, and 5xx responses to distinguish key, parameter, rate-limit, and upstream issues.
Calculate the cost per successful image task, not just the price per call.
Set rollback thresholds, for example switching back to the original chain if the success rate stays clearly below baseline for two consecutive hours.

FAQ

What is the difference between a relay and a direct Midjourney subscription?

A direct subscription is the official product, designed for human operation; a relay is an API-shaped wrapper for automation. They may differ in parameters, concurrency, and task visibility, and a relay also carries account-pool and terms risk.

Will a relay store my prompts and images?

It varies by service. Ask whether data is persisted, for how long, where, who can access it, whether it is used for training, and how deletion works. For client material, prefer providers with clear terms.

What if a task is lost on the relay side?

First check your local record by business order number, then the relay logs and the upstream task. If it cannot be recovered, you can only resubmit, so confirm before migration whether the relay persists task mappings.

Why do the invoice and the number of generated images not match?

Common causes include duplicate submissions, retries after failure, separately billed upscales and variations, different moderation-rejection rules, minimum spend, or expired balance. Ask for a breakdown by task ID and check it line by line.

Does migration require code changes?

If the relay is compatible with the existing interface, usually only the base URL, key, and a few fields change. If the state mapping or callback format differs, polling and persistence logic must change. Run shadow traffic first; most differences can be found in advance.

Next steps

Create a test key in ZSQH AI Gateway, validate the four links of submission, polling, download, and reconciliation with a minimal task, and then migrate gradually. Available models and costs are subject to model pricing, and prices may change.