Suno Retrieve Tasks (Ace Data Cloud)

Suno returns two tracks per generation. So three prompt variants is six songs, and if you're checking those with a chain of Retrieve nodes you've built a graph nobody wants to debug at 2am.

Suno Retrieve Tasks (Ace Data Cloud) is the obvious fix: one node, one list of task IDs, one status summary. Like its single-task sibling it only ever reads - nothing here submits a generation, so nothing here spends money. That distinction is the entire point of the pair.

How it works

The node is a thin wrapper over the same task endpoint the single-task node uses, POST /suno/tasks, with the action pinned to retrieve_batch and your IDs sent as an array. It parses ids_json into a list, builds one request, and then normalises every returned item independently before summarising them.

Two behaviours worth knowing before you trust the outputs:

One bad task doesn't sink the run. Each item is normalised in isolation, and a task the service reports as failed or malformed becomes an entry with status: failed and success: false inside the results rather than an exception. So a stale ID in your list won't stop the eight good ones.

The aggregate status is conservative. If any item is still pending, the node's status is pending - even when the rest are finished and their media URLs already sit in media_urls_json. If nothing is pending, any failure makes it failed; otherwise succeeded. So status answers "is the whole batch in", not "do I have audio".

The inputs

Only two, and this node has no model or action dropdown to worry about.

ids_json is where your task IDs go - a JSON array of strings, one line or pretty-printed, whatever's readable:

[
  "51332661-c7a0-4101-9ac3-46aefc55b4d3",
  "6f2a91dd-14c0-4b0e-9a77-2c0f7e5b1234"
]

An empty array throws "ids_json must be a nonempty JSON array of task IDs" and malformed JSON throws "ids_json must be a JSON array of task IDs" - both before any request goes out. parameters_json is there for the odd extra parameter; don't try to set action in it, because the endpoint hard-pins retrieve_batch and your value gets overwritten.

If you'd rather not hand-type IDs, anything that produces JSON text can be wired into ids_json - it's just a multiline string input.

Outputs, and one that lies to you

Six strings come back: status, task_id, media_urls_json, first_media_url, result_json, trace_id.

Here's the trap. task_id and trace_id are empty on this node. A batch lookup has no single task or trace behind it, and the client returns those fields blank by design. If you wire task_id downstream expecting anything, you'll get nothing and blame the wrong node. Per-task IDs live inside result_json, which is a JSON object shaped like {"items": [ ... ]} where each item carries its own status, success, task_id, trace_id, media_urls, and cleaned data.

What you actually wire is first_media_url → the Suno Load Audio node's audio_url input, which turns the link into a real ComfyUI AUDIO for Preview Audio or Save Audio. media_urls_json holds every URL from every task, flattened and de-duplicated - the pack's own test run against a single finished task got exactly two media URLs back, matching Suno's two-tracks-per-generation habit.

Install and key

Manager → Custom Nodes → search Suno, publisher acedatacloud, package Suno by Ace Data Cloud (Registry ID ace-suno). The pack's test notes the Registry wasn't listing it at test time, so if Manager shows nothing:

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

That pulls requests and jsonschema - the README says "only requests", which is out of date, and jsonschema is what validates your payloads, so don't prune it. No models, no GPU. Then the key, in the environment of the process actually running ComfyUI, followed by a restart:

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

Common issues

Because this is a query action, the client treats it as read-only and retries a failed connection up to three times - so a flaky network is not a reason to change anything, and looping it is genuinely safe. HTTP 401/403 is the usual key/Suno access/path restriction/content policy cluster, and HTTP 429 means back off. HTTP 5xx is where you go read your Ace request history before doing anything, using the trace ID from the console rather than from this node's (empty) output.

Two realistic gotchas beyond that. Task IDs must be IDs you own - someone else's or a stale one comes back as an error item or a 4xx on the whole call. And don't read pending as "the batch produced nothing": check media_urls_json first, because the tasks that did finish are already in there.

The usual framing applies while you're deciding whether this is worth a paid tier at all: our KB's audio survey is clear that the hosted path still owns clean vocal songs, while local ACE-Step handles instrumentals for free - and per the API-node doc, an array of your task IDs is one more thing leaving your machine.