The unified asynchronous generation endpoint. One path serves every modality: images and video today, with audio arriving here later at the same path and the same shape.

Unlike the vendor-compatible endpoints it does not wait. It returns a task ID immediately and generation continues in the background.

High-quality image generation often takes 80-115 seconds in practice, and any timeout along the synchronous request path can leave the client without a result even though upstream generation and billing have already occurred.

Billing matches the synchronous path: an upper bound is reserved at submit, then settled against actual usage. An insufficient balance returns 402 at submit time.

Edits with reference images use this endpoint too: switch the Content-Type to multipart/form-data and send reference images as files (image or image[]), with mask for the optional mask.

Model-specific parameters are not here

This endpoint serves every modality, and each model takes a different set — images have size / quality, video has duration and frame rate, audio has voice and sample rate. Putting them in one table means most of it does not apply to any given call, and nothing tells you which parts do.

So only the model-independent fields are listed here. For what your model accepts and what each field allows, see that model's own reference (grouped by model under Images).

Callbacks: webhook_url

When the task reaches a terminal state, the platform POSTs this payload to that address:

{
  "event": "task.succeeded",
  "sent_at": "2026-09-01T04:31:00.000Z",
  "task": { … }
}

task uses the same schema as GET /v1/tasks/{id}, so the same parsing code can be reused.

Verify the signature

The request carries Amux-Signature: t=<unix seconds>,v1=<hex>, an HMAC-SHA256 over ${t}.${raw body}.

Without signature verification, any party that learns the URL can forge callback payloads. The signing secret is derived per workspace — one per workspace — and workspace admins can view it on the API keys page in the console.

The signature covers t.body rather than the body alone, so stale timestamps should also be rejected. A five-minute acceptance window is a reasonable default.

Retries

Anything that is not 2xx (3xx included) and any timeout counts as a failure. After the first try we back off 10s / 1m / 5m / 30m / 1h, retrying at most five more times (six in total, spanning about two hours). So:

• Return 2xx quickly and move downstream processing onto your own queue;
• Deduplicate on task.id, because retries can deliver the same event more than once.

Redirects are not followed

The callback endpoint must return 2xx directly. Any 3xx response counts as a failure.

This endpoint does not stream

stream: true, and partial_images above 0, return 400 here.

Streaming would mean this request runs the work to completion and pushes it down the connection — the task never enters the queue, and the result is gone when the connection drops. Surviving a dropped connection is the reason this endpoint exists.

For the result within this request use Prefer: wait below, which returns exactly the same JSON as GET /v1/tasks/{id}. For low-resolution preview frames use the vendor-compatible /v1/images/generations with stream: true.

{
  "model": "openai/gpt-image-2",
  "prompt": "A ginger cat running through fresh snow"
}

{
  "id": "task_01M1CG35C16CJ790D00BV1RBVM",
  "model": "openai/gpt-image-2",
  "cost": "0.2108",
  "notes": [
    "dropped audio: this model decides the soundtrack itself"
  ]
}