GPT Image Retrieve Tasks (Ace Data Cloud)
Ten Task IDs, One Call, No Re-Generation
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
You ran a batch, walked away, and now you have a list of task IDs and no images. This node takes that list and returns every result in one shot - without submitting anything, which means without paying for anything again. It's the bulk version of GPT Image Retrieve Task, and for anything more than two jobs it's the one you want.
What it's for
Bulk recovery and bulk collection. Fan out a handful of generations, keep the IDs (log them somewhere; the nodes give you the task_id output for exactly this reason), then come back later and pull all the finished media at once. Because the action is a read-only query, the client may safely retry it on a flaky connection - the opposite of the submit path, where a dropped response is never retried because retrying could bill you twice.
The inputs that matter
ids_json is the point of the node: a JSON array of task IDs, like ["6f1c…", "9a02…"], with one ID per line accepted as well. It must be non-empty and it must parse - the node raises "ids_json must be a nonempty JSON array of task IDs" otherwise. Everything else is optional filtering and paging, and every one of them is a plain string widget that gets omitted when you leave it blank: trace_ids (a JSON array or newline list of trace IDs, for when you kept the wrong handle), type to narrow to images, images_generations or images_edits, offset and limit for paging, created_at_min and created_at_max as numeric epoch bounds (they're typed as numbers, so a date string won't validate), count_mode as none or exact, plus application_id and user_id which you almost certainly never set. parameters_json takes the same fields as JSON if you'd rather drive it from a file.
The action itself is fixed: the node always queries with retrieve_batch. There's no selector to get wrong.
What comes back
The interesting part is how it handles a mixed bag. Each returned task is normalized individually, and - unlike the single-task node - a broken or failed ID doesn't blow up the whole run. It becomes a failed stub in the list while the other items come through intact. The aggregate status is pending if any task is still running, failed if any task failed, otherwise succeeded.
That means the headline status is pessimistic by design: one bad ID in twenty marks the batch failed even though nineteen images are sitting in the output. Don't bail on the status - read media_urls_json, which collects the URLs from every item that has them, and first_media_url for the first one. result_json holds the per-item detail, which is where you go to find out which ID misbehaved. And pending on your first call usually just means slow jobs: run the same node again.
The task_id and trace_id outputs are empty strings on this node - it's a collection, not a single job, so the per-item identifiers live inside result_json.
Install
It ships with the pack. Manager: search GPT Image, publisher acedatacloud, package GPT Image by Ace Data Cloud; registry ID gpt-image. Manual, if the listing isn't live yet:
cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/GPTImageComfyUI
python -m pip install -r GPTImageComfyUI/requirements.txt
Then restart, and export ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) in the ComfyUI process environment first - a key set in another terminal isn't visible to the server.
Where people trip
Thinking this is a history browser. It queries by ID (or by the filter fields); it's not going to hand you "everything I did last Tuesday" unless you supply the filters and the service honours them. The sibling GPT Image List Tasks node is the one with the action selector, and it wraps the same task endpoint - if you're unsure which to reach for, that's the browsing-shaped one and this is the collection-shaped one.
Confusing a queried task with a new submission. This node never creates work, so a run here is immediate and free; a slow return means the service's response is slow, not that you've queued something.
Dumping twenty IDs at once and expecting twenty images back now. The batch is only as ready as its least-finished member. Re-run until you get succeeded, then load the URLs with GPT Image Load Image - remembering that the loader only accepts Ace CDN links, so extracting a URL from result_json and stuffing it into some other downloader is a dead end.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| trace_id | STRING | — | |
| trace_ids | STRING | — | |
| application_id | STRING | — | |
| user_id | STRING | — | |
| type | STRING | — | |
| offset | STRING | — | |
| limit | STRING | — | |
| created_at_min | STRING | — | |
| created_at_max | STRING | — | |
| count_mode | STRING | — | |
| ids_json | STRING | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |