kling/kling-4.0-flash-omni

Kling 4.0 Flash Omni, the fast Kling 4.0 tier, served direct from Kling.

One model for text-to-video, a first frame, reference images, reference videos, video editing and elements: up to 10 images, 5 input videos and 7 elements, 3 to 20 seconds at 720p.

Send Kling's own body: contents, settings and options.

Billed per second of the duration you ask for, which is required here: $0.0942; with input videos, $0.0628 a billed second, on the input and the output seconds (Kling's list price).

Kling 4.0 Flash on this gateway: kling/kling-4.0-flash-i2v · kling/kling-4.0-flash-omni (this page) · kling/kling-4.0-flash-t2v.

Slug	kling/kling-4.0-flash-omni
Kind	video
Vendor	kling
Endpoint	POST /v1/kling/generations

Charged per job from what the generator reports it rendered — your Logs show the exact figure for each one; see balance and billing.

Calling it

curl https://api.sociaro.com/v1/kling/generations \
  -H "Authorization: Bearer $SOCIARO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "model": "kling/kling-4.0-flash-omni",
        "contents": [
          {"type": "prompt", "text": "a paper boat drifts down a rain-soaked street"},
          {"type": "first_frame", "url": "https://your-cdn.example.com/first.png"}
        ],
        "settings": {"duration": 5}
      }'

# then poll the job id it returns:
curl https://api.sociaro.com/v1/kling/generations/JOB_ID \
  -H "Authorization: Bearer $SOCIARO_API_KEY"

Parameters

Kling 4.0 Flash Omni — text, a first frame, reference images or input videos to video

Anything not listed here is refused rather than ignored, so a typo fails loudly instead of quietly producing something else.

Worked example

curl https://api.sociaro.com/v1/kling/generations \
  -H "Authorization: Bearer $SOCIARO_API_KEY" -H "Content-Type: application/json" \
  -d '{ "model": "kling/kling-4.0-flash-omni",
        "contents": [ { "type": "prompt", "text": "the jacket from @image_1, worn on a windy pier" },
                      { "type": "refer_image", "url": "https://your-cdn.example.com/jacket.png", "id": "image_1" } ],
        "settings": { "duration": 10, "aspect_ratio": "9:16" } }'

curl https://api.sociaro.com/v1/kling/generations/{job_id} -H "Authorization: Bearer $SOCIARO_API_KEY"

Submit and poll. Send kling/kling-4.0-flash-omni to POST /v1/kling/generations and poll GET /v1/kling/generations/{job_id}. It is also served on the Jobs API (/v2/jobs), with the same body as input.

Input videos. A feature_video is a reference to follow (its motion, its rhythm, its camera); a base_video is the video to edit: say in the prompt what to change and what to keep. Each is a public https URL, never base64. At most 5 videos, at most one of them a base_video (the gateway counts the base_video among the 5). Each video, and all of them together, must be 3 to 20 seconds: the gateway reads each one's length from the file's own header when you submit (an MP4 or MOV that is not fragmented, at a URL that answers without a redirect), and a length it cannot read, or outside 3–20 s, is a 400 before anything is sent. Kling judges the rest when the job is submitted: .mp4 or .mov, up to 300 MB, 700 to 4553 px a side and at most 8,294,400 pixels in all, an aspect ratio between 2:5 and 5:2, 24 to 60 fps. With settings.audio: original the video keeps the base_video's sound, else the first feature_video's.

Elements. An element is a character or an object Kling keeps from your images. Make one on POST /v1/kling/elements (Kling's own body), get the task until it succeeds, and name the element_id here, with an id to cite it in the prompt as @id: at most 7. They are your organisation's, shared by its keys and nobody else's; Kling's presets (GET /v1/kling/elements/presets) are everyone's. Any other id is a 404 and nothing is sent, whether it is another customer's or nobody's. An element made from a video is not available on this gateway yet. An element is free, and naming one here adds nothing to the price. There is no delete route: to remove an element, ask support: an operator deletes it at Kling. The routes: Generations API.

Refused here, each a 400 before anything is sent: a request without settings.duration; more than 10 images, 5 videos, 7 elements or 15 inputs in all, or more than one base_video; a video that is not a public https URL; an element made from a video; a middle_frame, last_frame or voice part, and settings.multi_shot, 1080p and 4k, which Kling 4.0 Flash does not have; a settings.audio other than native or original; options.callback_url (poll instead), options.external_task_id (the gateway sets its own), options.watermark_info.enabled: true; a top-level prompt (the prompt is a contents part) and any other field Kling does not define. The body is capped at 1 MiB, so images and videos go in as URLs.

How it is billed. Kling's list price, billed once when the job completes; a failed job is not billed. Without an input video: settings.duration seconds at $0.0942 a second. The example above, 10 seconds, is $0.942.

With input videos the billed seconds are Kling's: twice the output when the input videos together are no longer than it, else input plus output. The input seconds are the ones Kling reports on the finished job (usage.input_duration), never rounded to whole seconds, and only those: the length the gateway reads when you submit only holds each video to 3–20 s. Until Kling reports them the finished job answers processing; the poll that completes it passes Kling's usage on as Kling sends it. A 15 second clip following an 8.03 second video: 8.03 ≤ 15, so 15 × 2 = 30 billed seconds × $0.0628 = $1.884. 10 seconds editing a 12.5 second video: 12.5 > 10, so 12.5 + 10 = 22.5 billed seconds × $0.0628 = $1.413.

How a job runs

Generation takes longer than a request should wait, so it goes in three moves: submit, then poll, then collect.

# 1. submit — the model id plus the fields above
curl -sS https://api.sociaro.com/v1/alibaba/generations \
  -H "Authorization: Bearer $SOCIARO_API_KEY" -H "Content-Type: application/json" \
  -d '{ "model": "…", "prompt": "…" }'
# -> { "job_id": "<id>", "status": "submitted" }

# 2. poll every 3-5 s for images, 5-10 s for video
curl -sS https://api.sociaro.com/v1/alibaba/generations/<id> \
  -H "Authorization: Bearer $SOCIARO_API_KEY"
# -> { "job_id": "…", "status": "processing" }
# -> { "job_id": "…", "status": "completed", "model": "…",
#      "media_url": "https://api.sociaro.com/v1/media/<media_id>" }
# -> { "job_id": "…", "status": "failed", "model": "…", "error": { "code": …, "message": … } }

# 3. collect within the hour — the opaque id IS the credential, no header needed
curl -sSL "https://api.sociaro.com/v1/media/<media_id>" -o out.mp4

Use the job_id verbatim as the path segment when polling: the two names are the same value. Which submit and poll URL this model uses is at the top of this page, under Calling it.

Reading the poll

status is one of processing · completed · failed. Only completed carries media_url, only failed carries error.

Gate on status, never on the poll's HTTP code. A poll-time failure is HTTP 200 with status: "failed" and an error object of { "code", "message" }, plus provider_code when the generator supplied one — on every failure branch, including one where the result could not be delivered. A submit-time rejection is different: it comes back as its own HTTP status with the reason in the body.

code is ours and stable; message is the generator's. Match on code: it comes from a small fixed set, and provider_failed still means what it always meant. A rejection of what you sent — a size out of range, an unusable input — additionally sets code: "invalid_request", because that is a different thing for your code to do. message now carries the generator's own sentence, and provider_code its own code (OutputVideoSensitiveContentDetected.PolicyViolation, IPInfringementSuspect), so a moderated generation, a copyright refusal and a broken renderer are finally distinguishable. Treat provider_code as informational: the vendors change these strings without telling us, so branch on ours.

message is variable text, capped at 400 characters. It used to be a single fixed 43-character sentence, so if you compare it by equality or keep it in a narrower column, that needs changing — match on code, and on provider_code when you need the finer distinction.

Two things that text is not. It does not name the generator behind the model: the names of the services and hosts that actually run your job are substituted out before you see it, so do not parse it for one. What it does not hide is a name you already have — the halves of the model id you called (alibaba, bytedance, wan, qwen, seedance, seedream, happyhorse) stay as written, because blanking those would garble the message exactly where it is useful: Model alibaba/wan-2-7-image not found has to survive intact. And the text can quote your own request back: a moderation message often contains the fragment it objected to. That is why we do not write it into our own logs, and why forwarding or storing a failed poll's message is your decision to make rather than something to do by default.

Collecting the result

media_url points at our host, not the generator's. It is a capability: the opaque id is the credential, so no Authorization header is needed and anyone holding the link can fetch it. It expires within the hour — download rather than store the link.

Several images are not optional extras. An Alibaba image model asked for more than one picture (n above 1) is charged for the number of pictures the generator reports making, and every link it returns is delivered, never fewer than that number: media_urls lists all of them in the generator's order (present on every image result, even a single one) and media_url is the first. Each has its own link and its own expiry. If any one of them cannot be delivered the job is reported failed and nothing is charged — unlike a still or a layer, an image you paid for is never left out.

Rules the gateway adds

Two fields are ours and never reach the generator:

An unknown field is always a 400. Most generators reject one themselves; some accept it, ignore it, render something other than what you asked for and bill you — so we refuse it for you. Either way you get 400 unknown field(s): [...] naming the offender, never a surprise render.

Ranges and enums are the generator's own and we do not re-validate most of them, so an out-of-range value comes back as its rejection, in its wording and with its numbers. The one thing we DO check ourselves is resolution, because an unsupported tier is silently ignored rather than refused: you would ask for the higher tier, be handed a lower one, and be charged. The tiers on this page are read from what the vendor prices, so they change when the vendor publishes one.

Authentication

Authorization: Bearer <your-api-key> on submit and on poll. The key must be valid AND granted this model — 403 otherwise.

One deliberate exception on poll: a key that is over budget may still poll and collect a job it already submitted, so work you have already paid for is never stranded by a budget that ran out mid-generation. While the key is over budget the gateway cannot read its model list at all, so the per-model grant is not re-checked on those polls — a grant revoked after submit still collects that job. Ownership is always enforced: a job can only be polled by the key that created it, and submit is always refused in that state.