Kling Retrieve Tasks (Ace Data Cloud)

Why you'd batch the lookups

You queue five Kling shots, walk away for a coffee, and come back to five task IDs in five different nodes. Checking them one at a time is a chore; retyping them into generation nodes to "refresh" is a way to accidentally buy two more clips. This node takes an array of IDs and returns one answer for the group.

It's the plural sibling of Kling Retrieve Task, and it's read-only - no new paid work, and the only kind of request the client will retry on a network hiccup (three attempts, with backoff). Paid submissions get one shot; queries get three. That asymmetry is the whole reason the retrieve nodes are comfortable to poke at.

How it works

ids_json is a JSON array of task ID strings - real JSON, with quotes and brackets, entered as text in a multiline box. The node parses it, refuses anything that isn't a nonempty array, and posts it with action: retrieve_batch to the tasks endpoint. The action is fixed in the contract, so there's no selector to get wrong.

Then it normalizes each item in the response and collapses them into one status:

• any task still pending → the batch is pending
• otherwise any failed → the batch is failed
• otherwise → succeeded

If a single item in the response is malformed, that item is recorded as failed rather than blowing up the whole call. Sensible, if a little quiet about it - read result_json when the numbers don't add up.

A consequence worth internalizing: the aggregated status is a summary, not a verdict. A batch of ten clips where nine are done and one is still rendering reports pending. You don't get a per-task count on the node face, so result_json is where you look when you need to know which one is lagging.

Inputs and outputs

Two inputs:

• ids_json - the JSON array of task IDs.
• parameters_json - the escape hatch for extra API fields, {} by default.

Outputs are the pack's six STRINGs: status, task_id, media_urls_json, first_media_url, result_json, trace_id.

media_urls_json collects every media link found anywhere in the responses (image, audio, video and file URL keys), deduplicated. first_media_url is simply the first one - which is fine when you've batched one logical job and misleading when you've batched five. For anything with multiple results, parse media_urls_json or read result_json; don't trust the convenience field.

Wiring: media_urls_json into a PreviewAny is the honest beginner setup. You can push first_media_url into Kling Load Video, but only once you know which clip you're loading.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/KlingComfyUI
cd KlingComfyUI && python -m pip install -r requirements.txt
# restart ComfyUI

Manager: search Kling, confirm publisher acedatacloud and package Kling by Ace Data Cloud (Registry ID kling). Two dependencies, requests and jsonschema, and no weights to download. If you want the native media loaders, be on ComfyUI 0.39.0 or newer.

Key from the environment, and only the environment:

export ACEDATACLOUD_API_KEY=your_key_here   # then restart ComfyUI

Common issues

"ids_json must be a nonempty JSON array of task IDs." You typed a comma-separated list. It isn't that. It wants:

["8f14e45f-...", "c9f0f895-..."]

Bare UUIDs without quotes parse as neither array nor string and land you on the same error. Quote them.

A lookup is not a resubmit. Nothing here creates work, so a pending batch costs you time, not Credits. If you want to redo a clip, that's the generation node, and it's a fresh paid submission.

Empty media_urls_json with a succeeded status usually means the response shape didn't include the media keys the pack scans for. Check result_json - the pack strips request metadata and internal fields before returning it, but the media URLs themselves should be there.

The key must be in the ComfyUI process environment. Exporting it in a shell that isn't the one running ComfyUI has no effect; the pack reads the environment at request time, from the process that's already running.