Sarvam Saaras v3 API: Full Speech-to-Text Guide
Sarvam Saaras v3 API: What It Actually Solves
Most speech-to-text pipelines for Indian languages need two models chained together โ one to transcribe, one to translate. That adds latency, doubles your API cost, and gives errors two places to compound.
The Sarvam Saaras v3 API collapses that into a single call. It takes audio in any of 22 Indian languages plus English, and depending on the mode you pass, gives you back a transcript in the original language, a translation to English, or a romanized version โ without a second model in the loop.
If you are building a voice agent, a call-center transcription tool, or an EdTech app that needs to understand Hinglish and Tanglish without falling apart on code-mixed sentences, this is the model doing the heavy lifting under the hood.
๐ฏ Quick Answer (30-Second Read)
- Main solution: Use the
saaras:v3model on Sarvam's/speech-to-textendpoint with themodeparameter set totranscribe,translate,verbatim,translit, orcodemix. - When to use it: Any product handling Indian-language or code-mixed audio โ IVR systems, voice agents, meeting transcription, telephony at 8kHz.
- Main benefit: One model replaces separate transcription + translation pipelines, and it is built for noisy telephony audio out of the box.
- Limitation: The synchronous REST endpoint caps out at 30 seconds of audio โ anything longer needs the Batch or Streaming API.
- Recommendation: Start with the REST API for prototyping, move to Batch for recorded calls, and use the WebSocket Streaming API only when you actually need live, sub-150ms responses.
Choosing the Right Saaras v3 Endpoint
Sarvam ships three ways to hit Saaras v3, and picking the wrong one is the single most common reason developers think the Sarvam Saaras v3 API is "slow" or "broken." It is usually just the wrong endpoint for the audio length.
Step-by-Step: Calling the Sarvam Saaras v3 API
1. Get your API key
Create a key at the Sarvam dashboard. Export it as an environment variable โ never hardcode it:
export SARVAM_API_KEY="YOUR_SARVAM_API_KEY"2. Install the SDK
pip install -U sarvamai
# or
npm install sarvamai@latest3. Python โ transcribe or translate in one call
from sarvamai import SarvamAI
from sarvamai.core.api_error import ApiError
client = SarvamAI(api_subscription_key="YOUR_SARVAM_API_KEY")
try:
response = client.speech_to_text.transcribe(
file=open("call_recording.wav", "rb"),
model="saaras:v3",
mode="translate", # transcribe | translate | verbatim | translit | codemix
)
print(response.transcript)
print(response.language_code)
except ApiError as e:
if e.status_code == 422:
print("Audio over 30s or unsupported format โ use Batch API instead.")
elif e.status_code == 429:
print("Rate limit hit. Back off and retry.")
else:
print(f"Error {e.status_code}: {e.body}")4. JavaScript โ same call via REST
The Node SDK mirrors the Python client, but the REST call is the version you will actually debug when something breaks:
import fs from "fs";
const form = new FormData();
form.append("file", fs.createReadStream("call_recording.wav"));
form.append("model", "saaras:v3");
form.append("mode", "translate");
const res = await fetch("https://api.sarvam.ai/speech-to-text", {
method: "POST",
headers: { "api-subscription-key": process.env.SARVAM_API_KEY },
body: form,
});
const data = await res.json();
console.log(data.transcript, data.language_code);Pass a file object, not a path string. That single mistake โ file="audio.wav" instead of file=open("audio.wav", "rb") โ is behind half the 422 errors developers report.
The Better Way vs The Worst Way
The worst way: chaining a separate transcription model into a translation model, retry logic duplicated across both, and no handling for 8kHz telephony audio โ which just fails silently on models tuned for 16kHz.
The better way: one saaras:v3 call with mode="translate", mono audio, WAV at 16-bit PCM where possible, and explicit error handling for 422 (bad audio) and 429 (rate limit) separately โ they need different retry strategies, not the same catch-all.
My Take
Saaras v3 works because Sarvam stopped treating Indian-language ASR as a translation problem bolted onto English ASR - it trained on code-mixed speech directly, which is why Hinglish sentences do not fall apart mid-transcript the way they do on generic Whisper-style pipelines. Best case: teams building IVR and voice-agent products in India ship in weeks instead of months because they are not stitching two models together. Worst case: teams treat the 30-second REST limit as a bug instead of a design constraint, get inconsistent results on long calls, and blame the model instead of picking Batch or Streaming. Right now the whole Indian-language voice-AI space is consolidating around a handful of domain-tuned models instead of generic multilingual ones, because accuracy on regional accents and telephony noise matters more than raw parameter count. Where this is heading: real-time voice agents in regional languages become the default UI for support and government services in India within a couple of years โ and most teams are not yet building for the 8kHz, noisy, code-mixed reality that will actually ship in production.
REST vs Batch vs Streaming API
| Feature | REST API | Batch API | Streaming API |
|---|---|---|---|
| Max audio length | 30 seconds | 2 hours | Continuous |
| Processing | Synchronous | Asynchronous | Real-time |
| Best for | Prototyping, short clips | Recorded calls, meetings | Live voice agents |
| Latency | Seconds | Minutes (job-based) | Sub-150ms (Fast mode) |
| Diarization | No | Yes, with timestamps | No |
Real Developer Use Case
A fintech building a call-center QA tool needed to transcribe and translate Hindi and Hinglish support calls into English for a compliance dashboard. Calls ran 3โ20 minutes at 8kHz telephony quality - well past the REST API's 30-second cap.
The fix: route every recorded call through the Batch API with mode="translate", poll the job status endpoint, and pull diarized output with timestamps once complete. That gave them speaker-separated English transcripts without upsampling the audio or running a second translation pass - cutting their pipeline from two models to one and removing an entire retry-and-reconcile step from their backend.
Frequently Asked Questions
Does the Sarvam Saaras v3 API support real-time transcription?
Yes, through the Streaming API over WebSocket, with Fast, Balanced, and Accurate presets. Fast mode targets under 150ms time-to-first-token, which is what you want for live voice agents rather than the REST endpoint.
What is the difference between transcribe and translate mode?transcribe returns text in the original spoken language with proper formatting. translate converts the same audio directly to English text in one step, skipping a separate translation call entirely.
Can Saaras v3 handle telephony audio?
Yes. It is built for 8kHz telephony audio natively, so call-center and IVR recordings do not need upsampling before you send them to the API.
Why am I getting a 422 error on the REST endpoint?
Almost always audio over 30 seconds, an unsupported format, or passing a file path string instead of a file object. Switch to the Batch API for longer files and double-check you are opening the file in binary mode.
Is Saaras v2.5 still worth using for new projects?
No. Sarvam has flagged v2.5 for deprecation and recommends saaras:v3 with the appropriate mode for every new integration โ v2.5 only gets bug fixes, not new features.
Conclusion
Use the Sarvam Saaras v3 API when your product touches Indian-language or code-mixed audio and you want transcription and translation from a single model call. REST for quick prototypes, Batch for recorded calls over 30 seconds, Streaming for live voice agents. The one thing to get right immediately: match the endpoint to your audio length before you touch the mode parameter โ most integration pain comes from that mismatch, not the model itself.
Related reads: Best AI Coding Tools for Developers in 2026 ยท How Developers Use AI to Build Apps Faster