Veo Retrieve Tasks (Ace Data Cloud)

Batch generation is the normal rhythm with a metered video API: you fire off eight or ten submissions over an evening, walk away, and come back to a pile of task IDs. Checking them one at a time with Retrieve Task is fine for one or two. For a pile, this is the node.

It's the plural of Veo Retrieve Task, and like it, running it is free.

How it works

It POSTs action: retrieve_batch to /veo/tasks with an array of IDs. Read-only, so the client retries it up to three times with a short backoff if the network hiccups - the same treatment single retrieval gets, and the opposite of what paid submissions get. Nothing is generated, nothing is charged, and no new video is created.

Worth being clear about the shape of the pack here: there is no batch submit. You always submit one render at a time through the individual nodes. This is the read side of the batch story, and it exists so that polling ten renders doesn't mean building ten nodes.

The input and the output

• task_ids_json - multiline string, default []. A JSON array of task IDs, so it needs real JSON: ["abc123", "def456"]. Single quotes won't parse, and neither will a bare one-per-line list - that's this node's one syntax rule, and the client says Task IDs must be a JSON array. when you break it. Minimum one ID, maximum twenty, and they all have to be non-empty strings.

The output is a single results_json string: an array of rows, each with task_id, status, video_url and trace_id. Any task it can't resolve comes back with status: "failed" and empty fields rather than killing the whole call - so one dead ID doesn't cost you the other nineteen.

Using the output

results_json is a plain string, not a per-task set of sockets, and that's the honest limitation here: there's no video_url output pin you can wire into Load Video. In practice you send it to a text preview node and read it, which is exactly what you want for a status sweep - which finished, which is still pending, which URL to grab. If you want to act on one of them, copy that ID into a single Retrieve Task node and continue normally.

Install and key

ComfyUI Manager → Custom Nodes → search Veo → confirm publisher acedatacloud and package Veo by Ace Data Cloud → install, restart. Or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/VeoComfyUI.git
cd VeoComfyUI && python -m pip install -r requirements.txt

requests is the only dependency - no model files, no GPU. The pack requires ComfyUI 0.39.0 or newer because it works with the native VIDEO type. Authentication is still required for reads, from the environment of the running ComfyUI process:

export ACEDATACLOUD_API_KEY='paste-your-key-here'
python main.py

Where people get burned

Speed, mainly. This node does one sweep per run - it doesn't poll and wait the way Retrieve Task's wait_seconds does. So a batch that's still rendering comes back as a page of pending, and you run the node again a few minutes later. That's cheap and it's the intended pattern; it's only a problem if you expected the node to block until everything was done.

The twenty-ID cap is easy to hit if you've been queueing renders all day. Split into two nodes rather than trying to be clever with the array - the client rejects the whole request over twenty, it doesn't process the first twenty.

And keep your IDs somewhere durable. This node is a lookup; if you lose a task ID you've lost your route to a render you already paid for. Copy them into a text file or a note node as you submit. The Ace console will also have them against your request history, which is the recovery path if you didn't.