task_id to you synchronously the moment the request is accepted. You simply keep that task_id and hand it back to this Tasks API to look the task up later — there is no need to supply a custom trace_id (only do so if you want to correlate tasks against your own business identifier).
Tasks are persisted to the server only when the original image request was submitted with a callback_url. Synchronous (non-callback) calls are not stored.
Application Process
The OpenAI Tasks API is bundled with the existing OpenAI service. If you already have access to OpenAI Images Generations you can call this endpoint with the same authorization token — no additional application is required. There is a free quota available for first-time users, allowing you to use the API for free.Endpoint
| Action | Purpose |
|---|---|
retrieve | Look up a single task by id or trace_id |
retrieve_batch | List multiple tasks by ids, trace_ids, application_id, or user_id |
Request Headers
accept: application/jsonauthorization: Bearer {token}content-type: application/json
Single Task Query (retrieve)
Request Body
| Field | Type | Required | Description |
|---|---|---|---|
action | string | yes | Must be retrieve |
id | string | one of | Task ID returned synchronously by the original image request (recommended) |
trace_id | string | one of | Custom trace ID, only needed if you explicitly supplied one via trace_id on the original request |
id or trace_id must be provided. The normal flow is to use the id returned by the submit response — supply trace_id only when you want to look the task up by your own business identifier.
Code Example
CURL
Python
Response Example
When the task is found:id / trace_id the API returns an empty object:
Field Description
id— the task ID generated when the original image request was accepted.trace_id— the custom trace identifier you sent with the original request (optional, useful for client-side correlation).type— the upstream API type, e.g.images_generations,images_edits,chat_completions_image.request— the request body originally sent to the upstream image API.response— the final response returned by the upstream image API after callback completion.created_at/finished_at/duration— Unix timestamps (seconds) and elapsed seconds.application_id/user_id/credential_id— identifiers of the application, end-user and credential associated with the task.
Batch Query (retrieve_batch)
Request Body
| Field | Type | Description |
|---|---|---|
action | string | Must be retrieve_batch |
ids | string[] | Look up tasks by a list of task IDs |
trace_ids | string[] | Look up tasks by a list of custom trace IDs |
application_id | string | List all tasks for an application |
user_id | string | List all tasks for an end user |
type | string | Filter by upstream type (images_generations, images_edits, …) |
offset | int | Pagination offset (default 0) |
limit | int | Page size (default 12) |
created_at_min | float | Earliest creation timestamp (Unix seconds) |
created_at_max | float | Latest creation timestamp (Unix seconds) |
ids, trace_ids, application_id, user_id, or a created_at_* time window.
CURL Example
Response Example
End-to-End Example: Submit-and-Poll
The Tasks API is most useful in callback mode. In callback mode the submit endpoint returns thetask_id to you immediately, so the polling step just hands that task_id back to the Tasks API — no custom trace_id required.
Notes
- Tasks API requests are not billed — polling is free. Only the original image generation/edit request is billed.
- A task is created only when the original request includes
callback_url. Synchronous calls do not produce a queryable task. - Records older than the platform retention window may be removed.

