Get Cover Generation Details

What it's for

Suno's cover flow takes an audio file you upload and re-renders it in a new style, keeping the song recognisable. On KIE that's a task like any other, and this node reads that task's record back: is the cover done, and where is the audio?

Why would you need it instead of just using the generation node? Same three reasons as the rest of this family. The pack's cover/generation nodes submit and wait, so in a clean graph you get AUDIO out the other end and never touch this. But jobs escape graphs - an interrupted workflow, a submission from the kie.ai dashboard, an n8n flow - and then a record read is the only way back in. Or you deliberately built a callback-based flow and want to collect the result on your own schedule.

It's a read. No generation, no charge. Also: no upload. If what you actually want is to submit a cover task, that's the generation node's job - this is the lookup afterwards.

How it works

The node queries the cover task's record through the pack's shared KIE client using your saved key. The pack's status reader knows the Suno conventions: it reads a status field from 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, FAILED. So a failed cover comes back as a readable message from the provider rather than an empty socket.

One quirk worth flagging so it doesn't surprise you: Suno cover generation is one of the endpoints where KIE's documented transport model and the provider's own version label don't line up, and the pack carries a small adapter table to translate between them. Practically that means you don't pick a transport model - the node handles it - but it also explains why cover nodes look slightly different under the hood from a plain "generate music" node.

Inputs and outputs

No required inputs. KIE's documentation page for this record endpoint didn't publish a machine-readable request schema when the pack built its node catalog, so the node was generated from the fallback template, which for this family produces no required fields at all.

Optional:

• timeout_seconds - INT, default 1200, min 30, max 7200, step 30. The pack's wait budget for the request; useful if the queue is slow.
• expert_override_json - STRING, default {}, "Expert-only payload overrides for APIs whose documentation has no request schema yet." This is where the task ID goes. On a GET-shaped node the pack sends those keys as query parameters, so something like {"taskId": "…"} is the real mechanism. An empty override means the node asks about nothing.

The pack re-resolves documentation pages on demand, so a UI reload can bring genuine documented fields in later. If real inputs appear, use them.

Outputs: audio (AUDIO), url, all_urls_json, task_id, raw_json (STRING), credits_consumed, credits_left (FLOAT). raw_json holds the record; url holds the first extracted link. The audio socket reflects the API family's media kind 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 your key at Settings → KIE.ai Nodes Next → Connection. The pack validates it against KIE before saving, displays a masked fingerprint rather than the key, and keeps the stored value in ComfyUI's user config directory - not in your workflow JSON. KIE_API_KEY handles headless installs and wins over the saved key.

Requirements: requests, Pillow, numpy, PyYAML. No checkpoints, no VRAM, no models folder touched. On Windows the repo's dist/ folder has a one-click installer that finds Desktop, Portable and manual installs.

Where people get burned

Timing, again, and it's a bit more forgiving here than with a full song render - but a cover still involves uploading audio and re-rendering, so querying instantly gives you an in-progress record and a confusing result.

The other thing people trip on is metadata rather than mechanics: a cover task's audio_id matters, because the sibling utility nodes that need to choose which track they're talking about expect one. If you're chaining cover → stems → MIDI, grab the identifiers from the same task rather than mixing across runs.

And the standard caveat for anything routed through a reseller: your uploaded audio leaves your machine, the provider's filter still applies to it, and every call is metered. Per-call cost is the whole reason people wrap these APIs, and also the reason a careless batch loop gets expensive.