September 5, 2026 · 4 min · api · engineering · product
.mdKling AI Avatar API: video jobs and live conversations
What Kling Avatar v2's fal endpoint accepts and returns, how it differs from a live avatar session, and what to measure before choosing an integration.
A narrated product clip and an avatar answering a customer's next question need different application flows. If you are evaluating a Kling AI Avatar API, start with the output you need: a finished video to publish, or a conversation whose next line depends on the person watching.
This guide examines Kling Avatar v2 Standard through fal's documented endpoint and Realtime Avatar's live-call integration. The API details below were checked on September 5, 2026. The Kling example uses fal's credentials and SDK; a direct Kling integration needs its own provider documentation.
What the documented Kling endpoint returns
fal exposes fal-ai/kling-video/ai-avatar/v2/standard. Its required inputs are image_url and audio_url, with an optional prompt. The result contains a generated video file and its duration. See the provider's API reference for the request and response schemas.
The @fal-ai/client SDK can submit a job, check its status and fetch the result; the queue API also accepts a webhook URL. Keep FAL_KEY on your server. Your application supplies the narration audio and presents the returned video when generation completes.
For a scripted lesson, that gives you a useful review step: listen to the narration, render the clip, inspect it, then publish. If the script changes, budget for another render. This endpoint's documented output is a video artifact; these details do not establish the capabilities of every Kling product or access agreement.
Choose the application flow first
| Design question | Generated video | Live conversation |
|---|---|---|
| When is the speech decided? | Before submitting the render | As the user takes each turn |
| What does the interface manage? | Job progress, review and playback | Call connection, input, recovery and ending |
| What should the prototype prove? | A publishable clip with acceptable rendering cost | A complete conversation with acceptable response delays |
These are architectural choices. A training product might use prepared clips for its explanation and a live avatar for follow-up questions. Treat those as separate flows with their own loading states, costs and failure handling.
How a Realtime Avatar call fits
Realtime Avatar's quickstart connects a browser to a live call through the realtime-avatar TypeScript SDK. Your server holds the API key and authorizes the call. The client renders the conversation and exposes controls to end it. Begin with an available example avatar so that character creation is separate from the first integration test.
For a custom character, upload a portrait and wait for avatar preparation to reach ready before starting a call. Creating an avatar is asynchronous; receiving an avatar ID does not mean it can already accept sessions. The creation guide explains that lifecycle.
Design the call screen around the user's next action. Show connection progress, make microphone permissions understandable, keep the end control reachable on a phone, and offer a clear retry after a failed connection. An idle animation can keep the character visible while connecting, but it should not be counted as evidence that live media arrived.
Measure what the person actually experiences
A claim such as "fast avatars" needs a defined clock. For a generated clip, measure job submission to a playable result. For a conversation, record at least these intervals:
- Starting the call to the first rendered frame from the remote live stream.
- Finishing a spoken question to hearing the first audible reply.
- Interrupting a reply to the old speech actually stopping.
Connection events and HTTP success responses help diagnose the system, but neither proves the user saw or heard the avatar. Test on the devices and networks your audience uses, repeat the same conversation, and report both typical and slower results. Our startup and turn-latency guide describes a measurement setup. This article makes no latency guarantee for either integration.
Budget for the workflow you will ship
For generated content, count finished clips plus retries and revisions. For live interaction, model conversation duration and peak simultaneous calls. Those workloads need different estimates even when both start with one image.
Realtime Avatar uses credits shared by live time and generation. The advertised live-minute allowance assumes those credits go to calls; creating assets draws from the same balance. Use the current pricing page and call cost estimator for plan allowances, overage and concurrency limits.
Build one complete journey before committing: a reviewed clip that plays in your product, or a call that connects, answers a follow-up and ends cleanly. You can try the latter in Studio, then follow the SDK quickstart to put it in your own application.