Kling Elements (Ace Data Cloud)

The consistency problem, solved on someone else's server

Keeping a character recognizably the same across shots is the oldest hard problem in this hobby - it's the reason IP-Adapter, InstantID and PuLID exist, and the reason the field eventually drifted to reference-conditioned editing when those adapters plateaued. Kling's answer is called Elements: you upload a few reference images (or a short reference video) and a name, and the service stores a character element under your account. Later, a generation node references that element by ID and gets your character back.

This node is the CRUD front end for that store. It doesn't generate anything. It's the filing cabinet.

Where it earns its place: if you're making a multi-shot sequence, "element_id" is a far more stable handle than pasting the same reference image into every node and hoping. The element lives server-side, so you set it up once and every downstream Kling job in the pack can point at it.

How the actions work

action is an enum with five values - list, presets, retrieve, delete, create - plus the default (from JSON/default) sentinel, which lets the API pick. The client treats list, presets and retrieve as read-only: they don't create work, and they're the only requests that get retried on a network hiccup.

create is the interesting one, and it's picky in ways worth knowing before you spend a run on it. reference_type is either image_refer or video_refer, and which one you pick decides which of the two list fields you fill in. element_image_list wants a JSON object with a frontal_image URL and a refer_images array of {"image_url": "..."} objects, between one and three of them. element_video_list wants {"refer_videos": [{"video_url": "..."}]} - exactly one video. element_name is capped at 20 characters and element_description at 100, both validated locally against the published contract, so overlong names fail before anything is sent.

delete is destructive and gated: the API requires confirm: true in the payload, and the pack enforces this with a confirm BOOLEAN widget. Leave it off and you get "Set confirm to true to perform this deletion or archive operation" instead of a deleted element. That's the right default - a destructive action behind a checkbox you have to deliberately tick, in a tool where re-running a workflow is muscle memory.

Inputs and outputs

The full widget list is id, page_num, page_size, callback_url, element_name, element_description, reference_type, element_voice_id, element_image_list, element_video_list and confirm, plus action and parameters_json. You'll only touch a few at a time: action decides which ones matter, id targets an existing element, page_num/page_size paginate a list, and the three element_* fields are for creation. element_voice_id ties a voice to the character, which is how you get the same person and the same voice across shots. Note the pack-wide habit: everything is a STRING widget, including things that are conceptually numbers or objects. page_size gets typed as 20; the image and video lists go in as JSON.

Outputs are the pack's standard six STRINGs - status, task_id, media_urls_json, first_media_url, result_json, trace_id. For a create call, read result_json to get the element ID you'll paste into the generation node's element_list. For a list call, result_json holds the page.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/KlingComfyUI
cd KlingComfyUI && python -m pip install -r requirements.txt
# restart ComfyUI

Manager: search Kling, publisher acedatacloud, package Kling by Ace Data Cloud, Registry ID kling. Dependencies: requests and jsonschema. Nothing heavy, no model downloads.

export ACEDATACLOUD_API_KEY=your_key_here   # then launch ComfyUI

Common issues

Read-only actions are cheap; create is not necessarily. Queries against existing elements shouldn't spin up new paid work, but treat any mutation as billable and check the service's request history rather than assuming.

"Invalid element_name: does not meet the API's maxLength constraint." Twenty characters is short. "Guy Who Walks" fits; "My protagonist from the sci-fi short" doesn't.

The reference_type / list mismatch. Sending image_refer with element_video_list filled in (or the reverse) is the most common contract error here. Pick the type first, then fill the matching field.

A reference image needs a URL, not a local path. These fields take public HTTPS URLs. Files on your machine don't upload from this node; whatever you reference has to be reachable by the service.

Don't expect this to be the character-consistency story you may have read. Elements is a reference store, not a LoRA. It steers identity through the API's conditioning, and like every adapter approach in this space - character-consistency.md tracks the local equivalents - it gets close to a likeness rather than nailing it. Test on cheap models before you burn a kling-v3-omni call getting a character right.