KIE Seedance 2.0 Preflight

Seedance 2.0 is ByteDance's video model, and like everything in the Seedream/Seedance lines it's closed - an API product only, no weights. When a model like that costs real credits per run and supports a genuinely complicated request shape - first frame, last frame, reference images, reference video, reference audio, audio generation, web search - you want to know what you're about to send before you hit go. This preflight node is that sanity check, and it's the closest thing the pack has to a "don't spend money on a typo" button for Seedance.

It's the sibling of KIE Kling3_Preflight but for ByteDance's model. It takes the same inputs as the Seedance 2.0 video node, validates them, uploads the media so the payload contains real URLs, and hands you the exact createTask JSON - without submitting a generation task. No credits consumed, just the upload cost of your media leaving the machine.

The inputs worth understanding

• model - bytedance/seedance-2-fast (default) or bytedance/seedance-2. Fast for iteration, standard for quality. Same request shape either way.
• prompt - the required text prompt.
• first_frame / last_frame - the dedicated temporal frame slots. These are first-class controls, separate from references.
• reference_images / reference_video / reference_audio - ordered reference media. Upload order matters, because that's what defines the @Image1, @Video1, @Audio1 aliases the prompt can use.
• generate_audio - ask the model to synthesize audio, or leave it off.
• return_last_frame - whether the API returns the last frame too.
• aspect_ratio / resolution / duration - pinned to KIE's public example values (16:9, 720p, 15s defaults). The author notes these options are "pinned to the public examples" and should widen only after live API verification.

What comes out

Three outputs:

• seedance_data (KIE_SEEDANCE2_REQUEST) - the validated payload object, for chaining straight into the Seedance 2.0 video node.
• payload_json (STRING) - the exact request body that would be submitted, media URLs resolved.
• notes (STRING) - the validation summary: which scenario was detected (frame-only, frame + refs, mixed), which model, how many of each media type.

Read this before trusting it

The README is admirably honest about where the uncertainty lives. The @Image1..N / @Video1..N / @Audio1..N aliases are inferred from upload order by the node author - they are not a verified KIE API contract, and prompt-side reference semantics remain model-behavior dependent. In plain terms: preflight proves your payload is well-formed and matches the transport shape KIE's docs show, but whether @Image1 actually does what you hope in the final video is something you validate per workflow. The author also flags that KIE's marketing mentions optional lens locking with no verified request field for it - so don't expect it here.

Install

Manager (search "ComfyUI-Kie-API") or:

cd ComfyUI/custom_nodes
git clone https://github.com/gateway/ComfyUI-Kie-API

Restart, config/kie_key.txt (copy from config/kie_key.example.txt) with your key. No model downloads.

When to use it

Every time you change the media wiring. Seedance 2.0's mixed payloads - frames plus references plus audio - are exactly where a swapped wire produces a silent "that's not what I meant" run. Dry-run the new shape once, read the notes output, then chain seedance_data into the video node for the real run. That split is the whole point: check structure free, spend credits only when the structure is right.