Authentication

Each /v1 endpoint looks for a Kling4 API key in the Authorization header, sent with the Bearer scheme. A request without a usable key is answered with 401 invalid_api_key.

Authorization: Bearer sk_sd_example

A key acts on behalf of one Kling4 account. Tasks created with it, and the credits they spend, belong to that account, and every key on the account can read those tasks.

Creating a key

Go to Settings → API keys, give the key a name of up to 32 characters (prod-backend, staging-worker and so on), and create it. Kling4 shows the full secret one time only. After that it keeps nothing but a hash, so a lost secret cannot be displayed again: create a new key instead. Keys have no expiry date; they work until you revoke them.

Keeping a key private

Read the key from an environment variable such as KLING4_API_KEY or from a secrets manager, expose it only to the service that talks to Kling4, and make sure loggers and error trackers never record the Authorization header.

Rotating and revoking

A revoked key stops working straight away, and calls made with it get 401 invalid_api_key. To switch keys without dropping traffic, create the new key, deploy it, check in the Last used column that the old key has gone quiet, and only then revoke the old one. If you suspect a leak, revoke first and deal with the downtime second.

The same 401 also comes back when the account that owns the key has been suspended.

Limits that apply to a key

• 120 requests per key in each 60-second window, counted across all three endpoints, polling included. A window opens with the key's first request and closes 60 seconds later, however steady the traffic, and the count is shared by all Kling4 servers. Go over it and the API answers 429 rate_limit_exceeded with a Retry-After header: the seconds until the window closes.
• Create calls from one IP address are throttled before the key is even checked: keep them at least one second apart and under 20 a minute. These early rejections are 429 responses with a Retry-After header and a short body, {"error": "too_many_requests", "message": "Please retry after 1s."}, and they carry no request_id. Each server counts them separately, so treat them as a ceiling to stay under.
• Concurrent videos are capped by plan: higher plans can run more videos at once; the pricing page lists the cap for each plan. Videos started in the web app count toward the cap. One create too many returns 429 concurrent_generation_limit_reached; wait for a running task to finish before sending the next.

When you get a 429, honor Retry-After if it is present, otherwise back off exponentially with some random jitter. A 5 to 10 second polling interval per task keeps you far below the per-key limit.