Get Music Task Details

What it's for

Suno's music generation is the paid benchmark for "type a prompt, get a finished song," and the honest local alternative - ACE-Step - still trails it on vocals and lyrics. That's the reason the Suno nodes exist in this pack at all: sometimes the API is just the right call. The trade is that everything becomes a task, and tasks need to be read back.

Get Music Task Details is that read. You give it a task and it reports the job's state and results: the audio, the metadata, whatever the record holds. It's for the moments when a generation node isn't the one holding the answer - the job was queued from the kie.ai dashboard or an external automation tool, the workflow was interrupted, or you submitted with a callback and want to collect the finished track later.

No generation happens here, so nothing is billed. It's also not something you need in a normal flow: this pack's Suno generation nodes already submit and wait, and they hand you native AUDIO back when the job lands.

How it works

The node queries Suno's record endpoint through the pack's authenticated client. The pack knows how this family reports itself: for Suno results it reads a status string out of the response data, treats SUCCESS as complete, and raises a KIE API error on the terminal failure states - CREATE_TASK_FAILED, GENERATE_AUDIO_FAILED, CALLBACK_EXCEPTION, SENSITIVE_WORD_ERROR, and FAILED. That last one is worth knowing about: Suno's own content filter can kill a task at generation time, and it arrives as an explicit sensitive-word error rather than a mysterious empty result.

Because Suno generation goes through KIE's Market envelope, task records carry more than one track per task. That's why the sibling lyrics node asks for an audio_id as well as a task_id - the record is a container, not a single file. Keep that in mind when you're wiring: a task is not a track.

Inputs and outputs

There are no required inputs, which is precisely the problem worth explaining. KIE's docs page for this record endpoint didn't have a machine-readable request schema when the pack built its catalog, so the node was generated from the fallback template. Its only inputs are optional:

• timeout_seconds - INT, default 1200, range 30 to 7200, in 30-second steps. The pack's wait budget for the request.
• expert_override_json - STRING, default {}, "Expert-only payload overrides for APIs whose documentation has no request schema yet." This is where your task ID goes. On a GET-shaped node the pack sends those keys as query parameters, so something like {"taskId": "…"} is the actual mechanism. Leave it at {} and the node asks a well-formed question about nothing.

The pack re-resolves unresolved documentation pages on demand, so if KIE's page later yields a real schema, a UI reload can bring in proper documented fields. Use them if you see them.

Outputs: audio (AUDIO), url, all_urls_json, task_id, raw_json (STRING), and credits_consumed / credits_left (FLOAT). For a report call the substance is in raw_json, with url giving you the first extracted link; the audio socket reflects the API family rather than a promise that a status read produces fresh audio.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
pip install -r ComfyUI-KIE-Nodes-Next/requirements.txt

Restart ComfyUI, then set the key once at Settings → KIE.ai Nodes Next → Connection. The pack validates it before saving and only ever shows a masked fingerprint in the UI - the full key stays in the user config directory, not in the graph. KIE_API_KEY overrides it for headless installs.

Requirements are requests, Pillow, numpy, PyYAML. No checkpoints, no VRAM. Windows users can run the installer in dist/ to have the pack placed and the ComfyUI Python environment detected for them.

Where people get burned

The obvious one: people fill in fields that aren't there. There's no prompt box on this node and no task-ID box either, so if you're expecting a form to type into, check expert_override_json - that's the door.

Then there's the timing trap, which is sharper for music than for images because a Suno task can carry several tracks and takes a while. Asking for details before the task reaches a terminal state gives you an in-progress record, and in a graph with no status branch that looks like a failure.

And the Suno-specific irritation: content filtering. Tasks can fail on the provider's own moderation, and no amount of prompt rewriting around it helps - the refusal lives at the model. If a track failed with a sensitive-word error, that's the answer, not a bug in your graph. For material that keeps tripping filters, stay local: ACE-Step has no server-side opinion about your lyrics.