OmniHuman 2 API: Inputs, Limits and How It Works

What an OmniHuman 2 API request contains

A request has two required fields and one optional field. The image URL points to the person (or people) to animate; the audio URL points to the speech or song that drives the performance; the optional prompt describes motion, mood, scene details and camera movement. Results are typically delivered asynchronously through a queue: you submit, receive a request ID, then poll for status or receive a webhook when the video is ready.

• image_url — required; the still image to animate.
• audio_url — required; MP3 or WAV that defines length and lip sync.
• prompt — optional; supported in English, Chinese, Japanese, Korean, Spanish (Mexico) and Indonesian.

Input limits to validate first

Rejected requests waste time and sometimes money, so validate on your side before calling the model. The image must be a common format such as JPEG, PNG, WEBP, BMP, TIFF, GIF or HEIC, no larger than 30 MB, between 300 and 6000 pixels on each side, with a width-to-height ratio from 0.4 to 2.5. The audio must be WAV or MP3, at most 15 MB, and between 4 and 300 seconds long.

Browser recordings are usually WebM or Opus, which the model does not accept. Convert them to WAV or MP3 before upload — our studio re-encodes recordings to 22.05 kHz mono WAV, which keeps a five-minute clip under the size limit.

Output and billing

A completed job returns a video file URL and the duration used for billing, which matches the length of the input audio. Output is native 720p MP4. Provider URLs can expire, so production systems should copy the file into their own storage as soon as the job finishes rather than linking to the provider directly.

Because cost scales with seconds rendered, measure audio duration on the server — never trust a duration sent by the browser — and reserve the cost before submitting so concurrent jobs can’t overspend a balance.

A production-ready flow

The pattern we run for every render on this site:

1. 1Upload to private storageIssue short-lived signed upload URLs; never expose long-lived public links to user photos.
2. 2Verify server-sideRe-measure audio length and confirm both files exist before any charge.
3. 3Reserve, then submitAtomically reserve credits, submit the job, and refund automatically if submission fails.
4. 4Finalize idempotentlyOn webhook or poll, fetch the result, store the MP4, and mark the job done exactly once.

When the no-code studio is the better choice

Building the pipeline above takes days of work: storage, validation, queues, webhooks, retries and billing. If your goal is content rather than a product feature, our studio gives you the same OmniHuman 2.0 output with all of that already done. We don’t offer a public API ourselves; this site is designed for creators and marketers who want finished videos.

Handling failures and retries

Treat every job as something that can fail: the provider may reject an input, time out under load, or return a result that cannot be downloaded. Keep a status column (queued, running, done, failed) per job, make the finalising step idempotent so a duplicate webhook can’t process twice, and refund any reserved balance on failure.

Poll as a fallback even when you use webhooks. Local development machines can’t receive them, and production webhooks are occasionally delayed.

• Store the provider request ID before you return to the user.
• Re-sign input URLs with a validity window longer than the expected queue time.
• Log provider errors verbatim; they usually name the exact limit that was exceeded.