Generation status and result
/v1/images/jobs/{job_id}Poll the job a generation returned with 202: status, and the images once they are ready.
Request
job_idstringpathrequiredimg_…)Responses
completed
{
"id": "img_9f2c1b7e…",
"status": "completed",
"cost_usd": "0.027",
"data": [ { "b64_json": "iVBORw0KGgoAAAANSUhEUgAA…" } ]
}Details
Needs a key in Authorization: Bearer or x-api-key.
This is how a result is fetched after a 202. A job is visible only to the user who created it: someone else's real id answers exactly like a non-existent one — a leaked id must not even confirm that it is real.
The shape of the reply follows the status, and it is built around the money. completed — cost_usd (what was charged) and data with the images. queued / processing / unknown_submit — estimated_cost_usd, the size of the reserve that is still held. failed — cost_usd: "0", because a failed generation is not billed and its reserve has already been released.
A result stays retrievable for 7 days. After that the bytes move out of the database into the archive, result_url is cleared, and the same GET /v1/images/jobs/{job_id} answers { "status": "completed", "archived": true, "data": [] }. That means expired, not "the generation produced nothing" — store the images on your side as soon as you get them. The job row and its money are never deleted: retention moves the payload only.