TL;DR You can access supported Kling video models through CometAPI with a CometAPI account and API key, rather than completing a separate Kling developer onboarding flow. The current text-to-video route is POST /kling/v1/videos/text2video. It returns a task ID, which your backend polls until the task reaches succeed or failed. Model availability, parameters, pricing, and account eligibility can change, so verify the live model catalog and API documentation before production deployment.
Direct answer
The practical route is . If the Kling model you need is available to your CometAPI account, your server can authenticate with a CometAPI API key and call the corresponding Kling-compatible endpoint. For that route, a separate Kling API application is not part of the integration steps.
This distinction matters for teams that already use CometAPI for other models. The application keeps one credential-management surface and one provider relationship while adding a Kling video workflow. Your code still needs to use Kling’s video-specific request schema and asynchronous task lifecycle; “one API key” does not mean every provider shares one identical request body.
This article focuses on text-to-video because it is the smallest useful integration. CometAPI also documents image-to-video and other Kling workflows, but each has its own endpoint and parameter constraints. Start with one verified path, then add capabilities only after checking the current documentation.
Why this route can be useful for a development team
The immediate benefit is operational rather than magical. A team that already uses CometAPI can add an available Kling workflow without creating another direct provider integration, distributing another credential, or building a separate account-management path. That can reduce the number of secrets, billing relationships, and provider-specific client configurations your platform has to maintain.
The second benefit is architectural. Your application can expose a small internal video-generation contract—prompt, workflow, model, options, and job status—while a provider adapter translates that contract into the documented Kling request. If the team later evaluates another video model, the product-facing job model can remain stable even though endpoint paths, parameters, and output metadata differ.
The limitation is equally important: a consolidated access layer does not make the underlying models interchangeable. Prompt behavior, accepted media, latency, pricing, safety policies, and result schemas can vary. Keep those differences visible in configuration and tests instead of hiding them behind unsupported assumptions.
What this access route changes—and what it does not
What changes. You create and manage a CometAPI key, send requests to CometAPI’s Kling-compatible API, and track usage from the CometAPI side. This removes a separate direct Kling onboarding step from this particular access path.
What does not change. Kling remains the underlying model family. Provider-specific parameters, generation behavior, acceptable-use rules, model availability, and output characteristics still matter. CometAPI’s documentation also notes that provider request and response fields may differ, so treat the live endpoint reference as the contract for your implementation.
What you should verify before committing. Confirm that your account can access the required model ID, review the current price and rate limits, and run a small authenticated test. Do not design a production workflow around a model name found in an old blog post or cached example.
Before you start
You need a CometAPI account, an API key stored on your server, and a backend capable of running an asynchronous job. Keep the key in an environment variable such as COMETAPI_KEY; do not expose it in browser or mobile client code.
Open the Kling model catalog and confirm the model you intend to use is currently listed for your account.
Create a server-side API key in the CometAPI console and set it in your runtime environment.
Decide where your service will store the task ID and final video. The generation request returns a task, not the finished video file.
Choose the Kling workflow before you design the request
Start from the asset your product already has. If the user has only a written concept, text-to-video is the direct path. If the user has a still image that should remain the visual anchor, use the separately documented image-to-video route. Do not add an image field to a text-to-video request and assume the API will infer the workflow.
Workflow
Current create path
Use it when
Text to video
POST /kling/v1/videos/text2video
The input is a written scene or motion concept and no source image must be preserved.
Image to video
POST /kling/v1/videos/image2video
The input includes one source image that should guide the generated motion and visual identity.
The current image-to-video reference accepts a public image URL or a base64 image string and returns an asynchronous task. More specialized Kling workflows have their own pages and request constraints. Add them one at a time only when the product requirement and current documentation justify the extra adapter.
For a first production proof, use one workflow, one verified model ID, a short duration, and a small set of representative prompts. This isolates account access and task orchestration from subjective output evaluation. Once the pipeline is reliable, compare modes or models with a fixed evaluation set rather than changing several variables in the same test.
Make your first Kling text-to-video request
The current text-to-video endpoint accepts JSON and Bearer authentication. Begin with a short prompt and the smallest supported duration. The following request uses only fields shown in the current CometAPI reference:
curl https://api.cometapi.com/kling/v1/videos/text2video \
-H "Authorization: Bearer $COMETAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"prompt": "A small ceramic cup on a wooden table, steam rising in soft morning light",
"model_name": "kling-v3",
"mode": "std",
"duration": "5",
"sound": "off"
}'
A successful submission returns an object containing data.task_id and a task status. Save that task ID with your application’s job record. Do not keep the HTTP connection open while the video renders.
Field
Documented values
Implementation note
model_name
Current enum includes kling-v3 and earlier tracks
Confirm the live enum and account availability before deployment.
duration
5 or 10
Start with 5 seconds to validate the workflow.
aspect_ratio
16:9, 9:16, 1:1
Omit it only if the documented default fits your delivery surface.
mode
std or pro
The reference describes pro as higher quality and higher cost.
sound
on or off
This applies only to model tracks that support generated audio.
Handle the asynchronous task safely
Kling generation is asynchronous. For text-to-video, poll GET /kling/v1/videos/text2video/{task_id}. CometAPI’s task reference says a response may return the task directly or inside a data envelope, so the example normalizes both shapes. It also treats every nonterminal state as “keep waiting,” instead of assuming a fixed list of intermediate states.
import os
import time
import requests
API_KEY = os.environ["COMETAPI_KEY"]
BASE_URL = "https://api.cometapi.com/kling/v1/videos/text2video"
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
def submit_video(prompt: str) -> str:
response = requests.post(
BASE_URL,
headers=HEADERS,
json={
"prompt": prompt,
"model_name": "kling-v3",
"mode": "std",
"duration": "5",
"sound": "off",
},
timeout=30,
)
response.raise_for_status()
payload = response.json()
return payload["data"]["task_id"]
def wait_for_video(task_id: str, timeout_seconds: int = 600) -> str:
deadline = time.monotonic() + timeout_seconds
poll_url = f"{BASE_URL}/{task_id}"
while time.monotonic() < deadline:
response = requests.get(poll_url, headers=HEADERS, timeout=30)
response.raise_for_status()
payload = response.json()
task = payload.get("data") or payload
status = task.get("task_status")
if status == "succeed":
videos = task.get("task_result", {}).get("videos", [])
if not videos or not videos[0].get("url"):
raise RuntimeError("Task succeeded without a video URL")
return videos[0]["url"]
if status == "failed":
detail = task.get("task_status_msg") or task.get("task_result")
raise RuntimeError(f"Kling task failed: {detail}")
time.sleep(10)
raise TimeoutError(f"Kling task {task_id} exceeded {timeout_seconds}s")
task_id = submit_video(
"A small ceramic cup on a wooden table, steam rising in soft morning light"
)
video_url = wait_for_video(task_id)
print(video_url)
The terminal success string is succeed, not succeeded. When a task completes, copy the generated asset into storage you control if your product requires retention. Provider delivery URLs should not be treated as permanent application storage.
For larger workloads, use a queue or worker rather than polling inside a web request. CometAPI also documents callback URLs for Kling tasks. If you adopt webhooks, authenticate and deduplicate callback events, and retain a polling fallback for missed deliveries.
Design the application job lifecycle before you scale
Treat the provider task as one part of your own job record. Store an application job ID, workflow, requested model, provider task ID, query URL, current status, submission timestamp, last poll time, and output location. This gives your support and operations teams enough context to investigate a failed or slow generation without searching raw request logs.
Do not retry the creation request merely because the client did not receive a response. The provider may already have created a task. Persist your local job before submission, save the returned task ID immediately, and separate creation retries from status-query retries. The current text-to-video reference also documents external_task_id for application tracking; confirm its live behavior before relying on it as a deduplication mechanism.
const TERMINAL = new Set(["succeed", "failed"]);
function normalizeKlingTask(payload) {
const task = payload?.data ?? payload;
if (!task?.task_id || !task?.task_status) {
throw new Error("Kling response is missing task identity or status");
}
return task;
}
async function refreshVideoJob(job, apiKey) {
const response = await fetch(job.queryUrl, {
headers: { Authorization: `Bearer ${apiKey}` },
});
if (!response.ok) {
throw new Error(`Task query failed with HTTP ${response.status}`);
}
const task = normalizeKlingTask(await response.json());
const outputUrl = task.task_result?.videos?.[0]?.url ?? null;
return {
...job,
providerTaskId: task.task_id,
providerStatus: task.task_status,
terminal: TERMINAL.has(task.task_status),
outputUrl,
failureDetail: task.task_status_msg ?? null,
checkedAt: new Date().toISOString(),
};
}
This example deliberately does not translate every possible intermediate provider status into a product promise. Your worker keeps nonterminal tasks active, handles succeed and failed explicitly, and records the raw provider status for debugging. Add a separate application timeout so a stalled task does not remain open forever.
Use polling as the baseline because the task ID remains queryable. When the selected endpoint supports callback_url, a webhook can reduce repeated status requests, but it should not become your only recovery mechanism. The official polling and webhook guide notes that callback payloads can be provider-specific. Store the raw event, make processing idempotent by task ID, return a successful HTTP response quickly, and reconcile the terminal state through polling.
Production checklist for developer teams
Validate the model at runtime. Check the current catalog and fail clearly when a requested model is unavailable. Do not silently substitute a different model if output behavior matters.
Separate submission from retrieval. Store the CometAPI task ID, your own job ID, the selected model, and timestamps so retries do not create duplicate work.
Bound polling. Use a timeout, exponential backoff or a reasonable fixed interval, and a maximum retry count. Review CometAPI’s rate-limit and concurrency guidance before increasing parallelism.
Classify errors. Do not retry invalid parameters or authentication failures. Apply backoff to retryable rate-limit and platform errors, following the current retry guide.
Protect credentials and inputs. Keep API keys server-side, avoid logging secrets, and confirm that users have the rights to any prompts, images, or other source assets they submit.
Measure the full job. Track submission success, queue time, generation time, terminal failure rate, timeout rate, output retrieval success, and cost by model and mode.
Persist outputs deliberately. Download completed assets to your own controlled storage when your product needs durable access, then apply your retention and deletion policy.
Practical FAQs
Do I need a separate Kling developer account for this route?
No separate Kling developer onboarding step appears in CometAPI’s integration flow. You use a CometAPI account and API key. Access still depends on the model being available to your CometAPI account and region, so confirm that before committing to production.
Is the Kling API fully OpenAI-compatible?
Not for the video workflow shown here. It uses Kling-specific routes such as /kling/v1/videos/text2video and Kling-specific fields. You can manage the credential through CometAPI, but your adapter should preserve the provider-specific schema.
Which Kling model ID should I use?
The current CometAPI text-to-video reference uses kling-v3 in its first working example and lists several earlier model tracks. Use a model ID from the live endpoint enum and verify that it is enabled for your account. Do not assume the newest model is available everywhere.
Why does the first response not contain a video?
Video generation runs as an asynchronous task. The initial response returns a task ID. Poll the matching query route until task_status becomes succeed or failed, then read the result metadata.
Should I poll or use a callback URL?
Polling is easier for a first integration. Callbacks reduce repeated requests at scale but require an authenticated, idempotent receiver and recovery logic. Many production systems use callbacks as the primary path and polling as a fallback.
Can I use image-to-video through the same endpoint?
No. CometAPI documents image-to-video under a separate route, /kling/v1/videos/image2video. Follow that endpoint’s current request schema instead of adding an image field to the text-to-video example.
Should I begin with standard or professional mode?
Use std to validate authentication, request shape, task storage, polling, and output retrieval. The current reference describes pro as a higher-quality, higher-cost mode. Evaluate it with representative prompts only after the basic workflow works, and compare output quality together with generation time and actual cost.
How can I avoid duplicate generations during retries?
Create an application job record before calling the API and save the returned provider task ID immediately. Retry status queries independently from creation requests. Do not assume that repeating the same POST is idempotent. The endpoint currently documents external_task_id for tracking, but verify its current semantics before treating it as a deduplication guarantee.
Conclusion
For a US development team that wants to test Kling video generation without completing a separate direct Kling developer application, CometAPI provides a documented route: verify that the required Kling model is available to the account, authenticate with a CometAPI key, call the workflow-specific endpoint, and track the asynchronous task to a terminal state.
The practical engineering value is centralized access and a reusable application job model—not the assumption that every video provider behaves the same way. Keep a thin adapter for each workflow, persist task identity and output deliberately, and retain polling as a recovery path even when callbacks are enabled.
A safe rollout is small and measurable: validate one model and one workflow, submit short low-cost jobs, record terminal success and failure rates, verify output retrieval, and compare actual cost and latency with your product requirements. Expand to image-to-video or additional Kling workflows only after the current documentation and your target account have been checked.
How to Use Kling API Without Direct Kling Onboarding: 2026 Guide - CometAPI
