api

Midjourney task compatibility protocol

Direct answerThe /mj/* routes are this site's task-proxy compatibility contract, not an official Midjourney public API. Confirm channel authorization and current terms, persist result as the task ID, and poll to SUCCESS or FAILURE.

Updated · Reviewed

Beginner: identify the site compatibility protocol

/mj/* is a site compatibility protocol, not an official Midjourney public API, and Midjourney does not endorse these paths, fields, or availability. Midjourney's terms can change and restrict automated access and resale. Before using the route, confirm that the account, upstream channel, authorization, and current terms permit the intended workload. A feature in the consumer product is not proof that the configured channel exposes it.

The site token is only for Authorization: Bearer $API_KEY on this site. Never place Discord credentials, a Midjourney login, or upstream secrets in client requests, browser code, or logs.

Minimal imagine request

prompt is required for imagine. Validate the contract with one low-cost prompt before adding callbacks, references, or follow-up actions.

create=$(curl -sS "$BASE_URL/mj/submit/imagine" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"A layered paper-cut rabbit in a moonlit forest, cinematic light"}')

task_id=$(printf '%s' "$create" | jq -r '.result')
test -n "$task_id" && test "$task_id" != "null"

An accepted response commonly contains code, description, result, and optional properties. code=1 means accepted; compatibility handling can also normalize queued or existing jobs. HTTP 200 alone is not completion. Stop when result is empty or the code is outside the accepted set, and retain a redacted response for diagnosis.

Poll status and consume output

curl "$BASE_URL/mj/task/$task_id/fetch" \
  -H "Authorization: Bearer $API_KEY"

The canonical retrieval pattern is GET /mj/task/{task_id}/fetch. The task object can contain id, status, progress, imageUrl, imageUrls, videoUrl, and failReason. SUCCESS and FAILURE are terminal. An empty status or progress below 100% can still mean queued or processing. Consume output only after SUCCESS, and retain failReason after FAILURE. Poll from a several-second interval with bounded exponential backoff, jitter, and an overall deadline.

Follow-up actions and channel affinity

Upscale, variation, edit, and video actions depend on the original taskId; some also require action, index, customId, or a mask. The site keeps follow-up work on the originating channel. Wait for SUCCESS, use buttons/customId values actually returned by the task, and never invent button IDs or reuse a task across accounts.

Creation has no universal idempotency guarantee. Store the caller job key, prompt hash, site Request-ID, returned task ID, creation time, and billing record. After a timeout, inspect that record before creating another billable job.

Media, safety, and output lifetime

Base64 references increase request and memory size. Bound bytes, pixels, types, and counts before decoding, and use bounded streaming paths. Remote asset fetches require SSRF, redirect, and response-size defenses. Obtain appropriate rights for people, brands, copyrighted inputs, and outputs, and enforce privacy, content, and commercial-use rules.

imageUrl and videoUrl may expire or require upstream authorization. Stream successful output into controlled storage and retain MIME type, byte length, hash, source task, access policy, and deletion time instead of treating a signed URL as permanent.

Expert: production and failure governance

Limit submit and poll concurrency independently; configure separate creation, query, and total job deadlines. Do not retry validation or moderation failures. Back off and reduce concurrency on 429, and retry only transient 5xx failures with a strict budget. Monitor acceptance rate, queue time, success rate, P95 completion time, duplicate rate, failure reasons, and output-retention success. Be able to disable the protocol quickly when a channel or its terms change.

Use cases

  • Submit an imagine job and retrieve progress
  • Run upscale, variation, or edit actions on a completed job
  • Govern idempotency, output retention, and terms compliance

API protocols

  • /mj/submit/imagine
  • /mj/task/{task_id}/fetch

FAQ

Is /mj an official Midjourney API?

No. It is a site compatibility protocol backed by configured task channels. Midjourney's documentation and terms do not endorse this route or response schema.

Is result in the submit response an image URL?

Usually not. On acceptance, result is the job ID for /mj/task/{task_id}/fetch. Read imageUrl, imageUrls, or videoUrl only from a completed job.

May I immediately resubmit after a creation timeout?

Avoid doing so. The upstream may already have accepted and billed the job. Check your idempotency record, Request-ID, and stored task before creating another job.

Official sources

  1. Midjourney Documentation Official
  2. Midjourney Terms of Service Official