KLingAI Query Status

This is the glue node of the whole pack, and the one beginners discover last, usually while staring at a task ID and wondering where their video went. KLingAI Query Status takes the task_id that any generation node spits out, polls the Kling API until the job is done, and hands you the result URL plus the video/image ID. Without it, your text2video and image2video nodes produce nothing you can watch.

Why this node exists

Every Kling generation is asynchronous. Submitting a prompt returns instantly with a task ID; the actual video takes minutes to render on Kling's servers. Someone has to sit there asking "is it done yet?" until the answer is yes. That someone is this node. It polls on a configurable interval, and when the status flips to succeed it extracts the result URL from the API response and returns it.

There's a clever bit under the hood: in auto mode it doesn't know which endpoint your task belongs to, so it tries all five (text2video, image2video, multi-image2video, lip-sync, image-generation), skips any that return 404, remembers the one that answered, and keeps using it. So you can mostly set task_type to auto and let it figure things out.

Inputs that matter

• api_token (required) - from the API Key node, same as everywhere else.
• task_id (required) - the ID from your generation node. external_task_id is a fallback if you're tracking jobs by your own ID instead.
• task_type - auto by default. If you know what you submitted, setting it explicitly (text2video, image2video, multi-image2video, lip-sync, image-generation) avoids the guessing and the 404 round-trips.
• initial_delay_seconds - 0 to 60, default 10. A little patience up front so the server has time to accept the task before you start hammering it.
• poll_interval_seconds - 5 to 30, default 10. How often to ask "done yet?" A shorter interval snags results sooner but costs more API calls, which matter if you're watching your credit spend.

The outputs

• url (STRING) - the direct URL to your finished video (or image, for image-generation tasks). This is the one you want.
• id (STRING) - the result's ID, returned alongside the URL.

Wire url straight into the KLingAI Video Downloader or Image Downloader to pull the file down. Two-node finish line.

How it fits

Typical graph: API Key → Text2Video/Image2Video/Image Generation → Query Status → Downloader. This node is the long pole - the queue blocks while it waits, so a 10-minute Kling render means a 10-minute "busy" queue item. That's expected, not a bug; go make coffee.

Where people get burned

• Setting task_type wrong. A mismatch means every poll returns task-not-found and it burns through 10 retries before giving up with an error string. auto saves you from yourself.
• Expecting the video here. This node returns a URL, not a file and not a tensor. The URL can expire, so downloading promptly is the right move.
• Long renders + short patience. If your queue dies mid-poll, the task keeps rendering server-side - you can re-run this node with the same task_id and pick up where you left off, as long as you kept the ID.
• Reading too much into task_status at creation. It's submitted/processing-flavored until this node's loop catches the flip to succeed. The status string on the generation node is just the starting snapshot.