Suno Retrieve Task (Ace Data Cloud)

If you take one habit away from this pack, take this one: submitting costs money, querying doesn't. Suno Retrieve Task is the querying side. Run it as many times as you like against the same task ID and your balance doesn't move.

It's also where the audio actually turns up. The submit node gives you a string; this node turns that string into a result you can wire into AUDIO.

What it does

Give it a task ID and it POSTs to /suno/tasks with action: retrieve - a read-only call, which is why the client is allowed to retry it up to three times on a dropped connection. Then it interprets the response: the pack walks the whole payload for status-ish and state-ish fields, and it only calls a result "succeeded" when everything it finds agrees. A response with no finished_at yet, or a status that isn't in the complete set, comes back as pending.

Both of those states are normal. A song takes a while.

The two inputs

task_id - the string from Suno Submit Music, pasted as-is. Empty is a hard error (The Suno task ID is required.), not a silent no-op, which is the correct behaviour: you want the failure visible, not a graph that quietly outputs nothing.

wait_seconds - an integer, 0 to 240, step 5, default 240. This is how long the node will sit and poll the same task before giving up on this run. It queries every five seconds and returns the moment the task stops being pending.

Be honest about what that means: the sleep happens inside the node, on the execution thread. A 240-second wait is a 240-second hold on your queue. For a long generation that's fine and simpler than any alternative; if you're running a batch, it's a reason to set wait_seconds low, let it return pending, and re-run just this workflow later.

The outputs

Four strings, and the last one is the useful one:

• status - pending or succeeded, straight from the API's own vocabulary.
• task_id - echoed back, so it can flow on.
• audio_url - the media link on Ace's CDN, empty until the task is done. This is what you wire into Suno Load Audio, which decodes it into a real ComfyUI AUDIO for Preview Audio or Save Audio. The node also prints "Audio is ready" or "Query this task ID again later" on the canvas as ui.text.
• trace_id - for support and for the console's request history when you need to prove what happened.

A failed task isn't returned as a status string - it raises (Suno task failed. Inspect the task and trace ID in Ace Data Cloud.) so it can't be mistaken for a slow one.

Install

Same pack, same one-time setup. Manager → search Suno → confirm publisher acedatacloud, package Suno by Ace Data Cloud (Registry ID ace-suno). Or:

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

requests and jsonschema, nothing heavier. The key goes in the environment of the ComfyUI process itself, then restart:

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

When it goes wrong

Still pending after 240 seconds. Completely normal for a slow queue. Re-run only the retrieve workflow with the same task ID. What you must not do is re-run the submit workflow - that's a second charge for the same song, and the pack is explicit about it.

A green queue entry. ComfyUI's queue going green means the graph ran without an exception. It does not mean the song exists. status has to say succeeded and the audio has to actually play.

HTTP 401/403. Key validity or Suno service access - a retrieve call failing this way is a config problem, not a task problem.

A 5xx or a connection error. Read-only queries retry automatically three times before surfacing anything. If it still fails, your task is unaffected; the song is queued on Ace's side regardless of whether you can see it from here.

Empty audio_url but a succeeded status. Rare, and the node treats "finished without an audio URL" as an error worth raising, because silently returning an empty string into an AUDIO loader produces a much more confusing failure two nodes later.