How to choose export formats
export_options decides which formats the pipeline auto-produces for each target language.
When you pass the parameter, only the formats you list are auto-exported. When you omit it, you get the full default set described below.
Omitting it produces video, audio, and MP3 — but never SRT. Subtitles are only auto-exported if you ask for them, so add srt explicitly. If you want a narrower set than the default, list exactly what you need: ["video"] produces the video alone.
The three formats
The “Use it for” column is suggested guidance from us, not API-defined behaviour. The “You get” column is what the API actually produces.
Ask for srt even when you only plan to ship video. It’s the cheapest way to review translation quality, since you can read the whole dub in seconds instead of watching it.
Audio-only sources cannot produce a video. If you upload a .wav or .mp3 and request video, that request resolves to audio — there is no source picture to re-mix onto.
Reading the exports back
export-status returns a flat array with one entry per (language, format). All formats for all languages come back in a single poll, and there are no per-language or per-format calls.
Group by target_language on your side and read download_url from each entry.
Set limit deliberately. It defaults to 5, and a job with 3 languages × 3 formats produces 9 entries, so the tail is not returned. Use a value comfortably above languages × formats (max 100).
Keep the id from each entry: it is the export_id used to download or cancel that specific export.
audio versus mp3
export_options accepts audio, but export entries can report an export_type of mp3 as well:
audio— uncompressed.wav, which is what you request.mp3— the same track re-encoded, which appears in the default set and fromexport-all.
You cannot ask for mp3 through export_options; it is not an accepted value, because a lossy re-encode is rarely what an API caller wants. Do still handle the value when switching on export_type, since it turns up whenever the default set runs.
The watermark on video exports
Video exports carry a Sarvam watermark by default. Pass disable_watermark: true at job creation for clean output. It applies to video only — audio and srt are never watermarked — and it is fixed at creation, so a job created with the watermark keeps it.
It also makes MP4 exports faster. Compositing a watermark forces a full re-encode of the video. With it disabled, an MP4 or MOV source is stream-copied instead — quicker, and with no generational quality loss. Sources in other containers are re-encoded either way.
Watermark-free export will become the default in a future release and the parameter will no longer be needed, so passing true today is forward-compatible.
Getting a format you didn’t request
Every setting is fixed at job creation and there is no update endpoint, but exports are separate from the job. A finished job can still produce a format you skipped, without re-dubbing and without re-uploading, because the translated audio already exists.
export-all ignores the job’s export_options on purpose, so a job created with ["srt"] can still obtain the video and audio later. Both re-export calls reuse a valid existing export rather than redoing the work, and report per-format reused, triggered, or already_in_progress.
Poll export-status afterwards exactly as you would for an auto-export.
These four endpoints are available over REST today. Dedicated Python SDK methods for them are on the way; until then, call them with any HTTP client using your usual api-subscription-key header.
Stale exports
Each entry carries an is_stale flag. It becomes true when the translation chunks for that language were edited (for example, in the Creator Studio editor) after the export completed, meaning the file you’d download no longer reflects the latest text.
Re-export with POST /jobs/{job_id}/export to refresh it.
Download URLs are signed and expire in roughly 24 hours. Persist the job_id and re-poll export-status for a fresh link, and don’t cache the URL itself.