Retrieve image task
Last updated September 7, 2026
Read a qwen/qwen-image-3.0 task result in Alibaba Model Studio's shape.
Look up a qwen/qwen-image-3.0 generation task; the response uses Alibaba Model
Studio's own shape. DashScope clients build this address themselves, so
retrieval keeps working once base_url points here.
https://gateway.amux.ai/api/v1/tasks/{id}Authorization
headerAuthorizationstringRequiredBearer <your Amux key> Your Amux API key.
Request
idstringRequiredThe task ID returned when you submitted.
Response
200responseAlways 200 whether or not it is done; the state is in task_status.
404responseNo such task, or it does not belong to this workspace. Both answer the same way, so that probing IDs across workspaces reveals nothing.
It reads the same task as the Amux endpoint
One task, two renderings — not two stores. New integrations should prefer
GET /v1/tasks/{id}, which also
carries usage and cost; the DashScope shape has no fields for them.
One behavioural difference from upstream
Upstream forgets a task after 24 hours and answers UNKNOWN. Our task rows are
never deleted and always return the real terminal state, so a client that treats
UNKNOWN as its give-up condition will never take that branch here.
Artifact URLs are ours
choices[].message.content[].image points at our storage rather than upstream's
signed temporary URL. It is cleaned up periodically, so download anything you
need to keep.
Errors
Errors come back in Alibaba Model Studio's shape. The type values and their retry semantics are in Errors and retries.
curl https://gateway.amux.ai/api/v1/tasks/{id} \
-H "Authorization: Bearer $AMUX_API_KEY"{
"output": {
"task_id": "task_01M1CG35C16CJ790D00BV1RBVM",
"task_status": "PENDING",
"choices": [
{
"finish_reason": "stop",
"message": {
"role": "assistant",
"content": [
{
"type": "image",
"image": "https://cdn.amux.ai/gen/20260907/task_01M1CG35C16CJ790D00BV1RBVM-0.png"
}
]
}
}
],
"code": "<string>",
"message": "<string>"
},
"request_id": "task_01M1CG35C16CJ790D00BV1RBVM"
}