Libraries & SDKs
Libraries & SDKs
Official Python and JavaScript clients for the Sarvam AI API — with async, retries, timeouts, streaming, and typed errors.
The official SDKs wrap every Sarvam AI API — Speech-to-Text, Text-to-Speech, Translation, Chat Completion, and Document AI — behind a typed, ergonomic client. They handle auth, serialization, multipart uploads, and error mapping so you don’t have to hand-roll HTTP calls.
Official SDKs vs. generated request snippets. The Python and JavaScript SDKs above are hand-tested, fully supported clients. The per-endpoint snippets you see in other languages (cURL, Go, Swift, etc.) on API Reference pages are auto-generated request examples — useful as a starting point, but only Python and JavaScript are first-class SDKs.
Initialize the client
Pass your API key directly, or let the SDK read it from the SARVAM_API_KEY environment variable.
Async usage
Both SDKs support fully asynchronous calls — use them when you need concurrency (e.g. fanning out many requests, or inside an async web server or voice agent).
In JavaScript, every method is already Promise-based — await it directly. In Python, the synchronous SarvamAI and asynchronous AsyncSarvamAI expose the exact same method names and arguments, so you can switch with a one-line change.
Timeouts and retries
Configure timeouts and automatic retries either globally (on the client) or per request. Per-request options override the client defaults.
Retries use exponential backoff and apply to transient failures (HTTP 429, 5xx, and connection errors). For a full retry/backoff helper and idempotency guidance, see Errors & Troubleshooting.
Handling errors
The SDKs raise typed exceptions mapped to HTTP status codes, so you can catch exactly the failure you care about. Catch the base class to handle everything.
Exception reference
¹ Auth failures return HTTP 403 (invalid_api_key_error), not 401 — see the auth status-code note.
Streaming support
Several APIs stream results instead of returning a single response. Here’s what each SDK supports:
- HTTP streaming returns an iterable/
BinaryResponseof raw audio bytes — see the HTTP Streaming guide. - WebSocket streaming uses the async clients (
AsyncSarvamAI/SarvamAIClient) with an event-driven connection — see the TTS WebSocket and STT WebSocket guides.
Document AI (file uploads)
Document AI is the one group that takes file uploads rather than JSON, so its call shape differs from the rest of the SDK. Both clients expose it as a doc_ai / docAi group, and a job is created in a single digitise() or extract() call.
Three call-shape gotchas, all specific to this group:
fileis a list, even for a single document. In JavaScript a bare stream fails withTypeError: request.file is not iterable.job_idis positional —getStatus(job_id), notgetStatus({ job_id }). Passing an object sends[object Object]as the path segment and the service rejects it as a non-UUID.schemais a JSON string, not an object, because it’s sent as a multipart form field —json.dumps(schema)in Python,JSON.stringify(schema)in JavaScript.
The JavaScript SDK is generated without a serialization layer, so request parameters and response fields use wire names (output_format, job_id, pages_processed), not camelCase. This is unlike the rest of the SDK.
See the Document AI overview for schema rules, output formats, and the full job lifecycle. The older document_intelligence group (create_job() / upload_file() / start() / wait_until_complete() / download_output()) is still present for existing integrations, but new work should use doc_ai.
Versioning
The SDKs follow semantic versioning. Pin a version in production and review the API changelog before upgrading across a major version. Always develop against the latest release: