Skip to main content
Midjourney uses a separate /mj/* task protocol, not the request or response format of /v1/images/generations. Configure a matching channel and use a gateway Bearer token. /{mode}/mj/* variants also exist; available modes depend on the deployment.

Minimal read example

Use the REST runtime with an existing public task ID. The script queries once, submits no generation, and downloads no returned URLs.
Successful reads return fields such as id, status, and progress. Business errors may use HTTP 200 with code / description; the example rejects that envelope and validates the ID and status. A successful process exit means the query succeeded; only completed: true means task success. imageUrl may be a signed gateway URL: keep it out of public logs. Video tasks also have videoUrl / videoUrls; do not assume every result is an image. See task API. A newly accepted task can temporarily have an empty status. The example labels it PENDING locally and does not mark it complete; this does not add a server status.

Submission and follow-up actions

MidjourneyRequest includes action-dependent fields such as prompt, taskId, customId, action, index, and base64Array. Submission typically returns code, description, result, and properties. Retain the task ID after business acceptance and query it; HTTP 200 is not image completion. Upstream proxies differ in action and customId formats. Obtain valid payloads from the operator instead of deriving parameters from button labels. The following routes are registered, but the table does not replace provider payload documentation. /mj/notify is not registered; a notifyHook DTO field does not mean the gateway hosts a callback receiver. Also available: GET /mj/task/{id}/image-seed for seeds and GET /mj/image/{id} for proxied images. Neither response is the task JSON contract. Avoid automatic generation retries and validate polling, business codes, and final artifacts against the selected upstream.
阅读中文版