Why a direct Midjourney API integration breaks under a stream of tasks
A direct Midjourney API integration looks temptingly simple: send a request, get a link to the image. Under a stream of tasks, this scheme starts losing tasks.
The generation service has generation request limits — they are counted not "on average per day" but in a sliding window, and under peak load some requests are rejected before they are even queued for processing.
A script that does not distinguish between "task rejected" and "task accepted, result is being prepared" silently loses half the requests.
The second break is timeouts. Generation takes tens of seconds, and a synchronous call does not survive the connection.
A retry without accounting for state creates duplicates: the same image is generated three times, paid runs are wasted, and a failure during mass generation shows up at the stage of assembling the final set — when half the frames do not match the original task list.
The third area is result delivery. Without automatic upload to your storage, images remain available via temporary links that expire, and manually downloading results becomes a regular operation.
At a volume of hundreds of images per day, this is hours of employee time and a constant risk that the needed frame is no longer available.
All three areas are closed by a single pipeline: a generation task queue that accounts for limits, idempotent retries, and automatic uploading of finished files to your storage. Below we break down how this is arranged and what the customer gets.
What a Midjourney API integration gives a product team
Direct generation calls from the product interface quickly hit limits: simultaneous requests queue up on the Midjourney side, and some tasks drop off due to exceeding the quota.
We place our own control layer between the product and generation — it manages the task queue, limits the number of parallel requests, and retries failed ones. The generation service throughput holds up during peaks instead of sagging during mass load.
Image delivery time stops being a lottery. Each request gets an identifier and status, the client retrieves the result on a readiness event rather than by constant polling, and on failure the task returns to the queue instead of being lost.
The team plans catalog or feed filling knowing how many frames will arrive per hour — content plan deadlines stop depending on how the external service responds.
The share of manual operations in the pipeline drops: preparing requests, restarting failed tasks, renaming and arranging files all become automated.
Quality control for generated images is built on formal checks — frame format and size, absence of duplicates by content match, filtering out empty and broken responses. Disputed frames go to a human for review rather than to publication.
A separate class of failures disappears along with scattered manual runs: there are no more lost tasks, accidental duplicates, or discrepancies between what was ordered and what was published.
Metrics for each step of the pipeline show where the bottleneck is, so changes are made based on data, not gut feeling.
Operating modes: synchronous tasks, queue, and batch generation
Image generation via Midjourney does not come down to a single call: the result does not arrive instantly, and the resilience of the solution under load depends on how waiting is organized.
Synchronous generation keeps the request in one connection — convenient for single tasks, but during a parallel burst handlers are busy waiting, and some requests are cut off by the wait timeout.
An asynchronous task queue separates intake and output: a request gets an identifier, the result is retrieved by status polling or a readiness notification, and retries with an idempotency key do not spawn duplicates.
Batch image generation solves a different problem — mass sets by catalog or template, where the assembled result as a whole matters more than the time for an individual image.
| Option | When it fits | Mode limitations |
|---|---|---|
| Synchronous call | Single images triggered by a user action: preview, edit, one generation per request | The connection is occupied for the entire rendering time; during a burst — wait timeouts, an already started generation cannot be canceled |
| Asynchronous queue | Deferred delivery, long tasks, unstable communication channels | Requires storing task states, handling failures and retries, in-flight cancellation; the result arrives with a delay |
| Batch generation | Catalogs, series of variations, mass reprocessing of an archive | Requires an agreed volume and schedule; an error in the template multiplies across the entire batch and costs a redo of the whole set |
In practice, the modes are combined: interactive work runs synchronously, and everything long-running and mass-scale goes through the queue. When analyzing a task, we look at the load profile and select a scheme in which peaks do not turn into failures.
Implementation stages: from scenario audit to handover to operations
A generation integration audit begins not with code but with an inventory of scenarios: where an image is needed, who requests it, and what happens to the result afterward. Without this, debates about style and the "right" frame turn into endless revisions. Then the work proceeds in stages, and each one is closed with a verifiable result.
- Generation integration audit. We analyze request sources, daily volume, acceptable response delay, and rejection points. The output is a list of scenarios with priorities and clear quality criteria.
- Data flow diagram. We lay out the path from the trigger event to the file in storage: queues, retries on failure, cache, logging points. We agree on the diagram before the first line of code.
- Test generation pipeline. We set up a separate environment with the same parameters as production, connect the Midjourney API, and limit quotas so test runs do not eat into the production quota.
- Load testing. We run mass generation, peak bursts, and connection drops. We look at where the queue grows and how the system recovers after an external service failure.
- Regulations. We document how to change styles and request parameters, what to do when the service is unavailable, who makes decisions, and how an incident is escalated.
- Integration acceptance and handover to operations. Running acceptance scenarios together with your team, handing over access, documentation, and the support procedure.
What we hand over: diagrams, regulations, and documentation
We deliver not only a working generation service on Midjourney but also a set of artifacts that your team can use to change configuration, handle incidents on call, and pass internal audits. Everything is described so that a new engineer can figure it out without contacting us.
- Pipeline architecture diagram: the request path from your service to the finished image storage, external dependencies, failure points, and areas of responsibility.
- Test and production pipeline configurations: limits on parallel tasks, response wait timeouts, retry rules, retention periods and parameters for results.
- Failure handling regulations: which errors are retried automatically, which go to manual review, who is notified and how by the on-call engineer, and what is recorded in the log.
- Access policy for the generation service: roles, scheduled key rotation, restrictions by request sources, separation of rights to launch tasks and read results.
- Generation integration documentation: methods, request and response formats, call examples, analysis of typical errors, and the procedure for making changes.
- Instructions for the on-call engineer: how to check the queue, restart a stuck task, return it to work, and roll back the configuration to the previous one.
- Set of metrics and alerts: share of successful generations, queue wait time, queue depth, and signals when failures increase.
Case study: how manual export was removed from the generation flow
Before: manual export
The design team retrieved generations manually: an operator opened Midjourney in a browser, copied the prompt from the spreadsheet, downloaded the result, and sorted it into project folders.
With a flow of 300–400 images per day, this took two employees up to six hours, and the queue of prompts grew faster than they could process it.
The bottleneck turned out to be not in generation but in transfer: each manual export was a point where the link between prompt, version, and task was lost.
If the flow broke, no one could say what had already been delivered, and a rollback meant reassembling the archive manually.
After: an operator-free pipeline
We assembled a queue on the service side: the prompt and parameters — aspect ratio, style reference, number of variants — are sent through the programmatic interface, while the task status and file link are returned via callback.
Images are stored in storage under the task identifier, metadata is written to the database, from which the internal panel retrieves it.
We added retries with increasing delay for network failures and duplicate filtering by prompt hash: a connection drop no longer causes repeated generation or a second copy of the file in the project.
| Metric | Before | After |
|---|---|---|
| Delivery of a finished frame | up to 6 hours | 8–12 minutes |
| Manual operations | 100% | ~3%, only selection of final variants |
| Link between prompt and file | lost on connection drop | held by the database |
The class of failures "the wrong frame was sent, file not found" was closed along with the manual stage: the link between prompt, parameters, and result is no longer stored in the operator's memory.
How does synchronous generation differ from batch processing?
Synchronous generation is a request in which the client waits for the image within a single connection, and the timeout sets the boundary of acceptable operation time. In the Midjourney API, this is a regular call: you send parameters — you get the result in the response.
Batch processing is arranged differently: the job goes into a queue, a worker picks it up taking the generator limits into account, and the result arrives via a readiness notification or status polling by task identifier.
The modes differ not in image quality but in where waiting accumulates and who is responsible for retry on failure.
In an interactive scenario, the synchronous mode wins: the user sees the result within seconds, without intermediate states.
The price is binding the worker to the connection: during a peak, threads hit the limits, and a connection drop after the job is accepted causes repeated generation and a duplicate.
The batch pipeline responds more slowly — from tens of seconds to minutes — but a failure of one job does not bring down the flow. The queue replays failed attempts, a retry with the same identifier does not create a second image, and priorities let urgent work go first.
Support complexity is also different. A synchronous gateway only needs timeouts and a concurrency limit, but it has no resilience margin for long series.
The batch pipeline requires a queue, state storage, and monitoring of stuck jobs: more components, but predictable behavior under load.
The choice of mode for the load is determined by volume and response requirements. Single requests with a user waiting — synchronously, with a short timeout and headroom on limits; mass runs of a catalog or series of variants — into the queue, where total throughput matters more.
More often we build a hybrid: a synchronous gateway for previews, a background pipeline for full series.
Common technical concerns before starting work
Before starting an integration, technical questions narrow to four: how many requests pass without degradation, what happens when the service is unavailable, where the results physically reside, and who has access to them.
Below are the analyses that most often come up at the estimation stage, with the answer "how it works for us."
What about quotas and limits of the generation service?
Limits constrain us on the queue side, not on the user side. Each direction gets its own pool of parallel requests, interactive tasks have higher priority than batch runs, and exceeding the pool does not bring down the service — tasks wait their turn. Batch catalog generation can be launched at night without competing with operators.
What happens if the service is unavailable or returns an error?
The job is not lost: it remains in the queue with retries and an increasing pause between attempts, and the task key prevents creating a duplicate on resend.
During a prolonged failure, work switches to a backup channel or is postponed, but already accepted requests do not disappear and reach the result after recovery.
Where are generated images stored, and for how long?
Files are written to object storage in the customer's pipeline, while metadata remains in the database: prompt, parameters, launch author, time.
Access is granted via temporary links, a lifecycle rule automatically cleans the archive according to the specified retention period — the catalog does not grow indefinitely, and the needed source files remain for repeated generation.
How secure is the generation pipeline?
Prompts and results do not go to external analytics services, access is delimited by roles, and all calls are logged. If personal data appears in prompts, we add anonymization before sending — the output is an image with no link to a specific person.
Describe the task — we will come back with an estimate, queue diagram, and work plan for your storage pipeline.Let's discuss the task and come back with an estimate and work plan
To make the integration estimate rely on facts rather than assumptions, a few inputs are enough at the start. The more accurately the scenario is described, the fewer assumptions we build into the plan.
- Scenarios: where exactly generation appears — product card, banner, publication cover, operator response.
- Volumes: how many images per day and on peak days, whether a queue and task priorities are needed.
- Examples: 10–20 references and typical descriptions that show the required style and quality.
- Integration points: admin panel, personal account, or external service — what already exists and what it runs on.
- Storage and delivery: where to put finished files, what sizes and formats are needed on output.
- Constraints: moderation rules, requirements for rights to the result, what we consider unacceptable content.
- Access: test pipeline, credentials for integration, and an engineer available on the customer side.
In response, we send an integration estimate broken down by stages and an integration work plan: which steps run in parallel, what depends on access, and where delays are possible.
As a separate block — risks and assumptions, so the decision is made without surprises halfway through.
Describe the task in free form — we will come back with an estimate, plan, and implementation diagram for image generation on Midjourney API.
