Kling AI Authentication

Kling doesn't take a single API key the way Gemini or ElevenLabs do. It uses a key pair - an access key and a secret key - and the secret is used to sign every request with a JWT. That means every Kling node in this pack needs a credential object, and that object comes from exactly one place: this node. It's the plumbing that the 30+ other Kling nodes hang off, and in practice it's the first node you drop on the canvas when you build any Kling workflow.

You'll reach for it once and leave it there. It takes your access key and secret key, packages them into a KLING_AUTH object with a debug flag, and outputs that object to be wired into every Kling node's auth input. There's no model, no API call - it's pure setup. Get your keys from the Kling developer console (app.klingai.com/global/dev), where you also activate API access for your account.

How it works

The node itself just assembles a dict - {access_key, secret_key, debug} - and passes it along as a KLING_AUTH typed output. The real machinery lives in the Kling client: when an actual API node runs, it builds a JWT signed with your secret key (the pack depends on PyJWT for exactly this), attaches it as the authorization header, and calls Kling's task-based API. Your keys never appear in the workflow file in plaintext - the inputs are password-masked, and the pack's environment fallback means you can keep keys entirely out of saved workflows.

The debug toggle is the sleeper feature: flip it on and every Kling API request gets verbose logging to the console. When a task fails and you can't tell why, that switch is the first diagnostic you'll reach for.

Inputs and outputs

• access_key - your Kling API access key. Leave blank to use the environment.
• secret_key - your Kling API secret key. Also env-fallback.
• debug - boolean; enables verbose request logging. Default off.

One output: auth (type KLING_AUTH) - wire it into the auth input on every Kling node.

The environment variables the code actually reads are KLING_ACCESS_KEY and KLING_SECRET_KEY. (The pack README says KLING_ACCESS_SECRET - the shipped code disagrees, and the code wins. If you set env vars and auth still fails, check you're using the right names.)

How to install it

Pack-level install, like the rest of the toolkit:

cd ComfyUI/custom_nodes
git clone https://github.com/IxMxAMAR/ComfyUI-API-Toolkit
cd ComfyUI-API-Toolkit
pip install -r requirements.txt

or "API Toolkit" from ComfyUI Manager. The Kling service specifically needs requests and PyJWT - both in requirements.txt. No model files.

Common issues

The error list is the pack's gift to you: the Kling client maps error codes to plain-English messages. The ones you'll actually meet: 1003 (account not activated for API access - new Kling accounts need approval before API calls work; that's a Kling-side waiting game), 401/1002 (bad keys), and 1102 (out of credits). If you get a 1001 "invalid token," regenerate your keys in the dev console - a stale secret signs a broken JWT.

One setup trap worth naming: debug on writes a lot of console noise, so turn it off for normal runs. And remember Kling tasks are asynchronous and billed per job - auth being free doesn't mean the nodes downstream are.