Sarvam Mayura API Tutorial: Translate Indian Languages

Introduction: Getting Started with the Sarvam Mayura API

Every Indian language SaaS product hits the same wall: translation quality for regional scripts. Google Translate handles Hindi fine but stumbles on Hinglish, code-mixed text, and less common scripts like Odia or Assamese. That is exactly why developers search for the Sarvam Mayura API, since it is built specifically for Indian language pairs and code-mixed input.

This guide walks through the actual integration: a secure Node.js proxy that hides your API key, a working frontend, and the parameters that matter. No theory, just a working translation sandbox by the end.

If you have ever shipped an API key straight to the browser and regretted it later, this pattern fixes that permanently.

Quick Answer (30-Second Read)

• Main solution: Use a Node.js server as a proxy between your frontend and the Sarvam Mayura API endpoint, POST https://api.sarvam.ai/translate.
• When to use it: Any product translating between English and Indian regional languages, especially with code-mixed or informal text.
• Main benefit: Native support for 22 Indian scripts plus auto language detection, without exposing your subscription key client-side.
• Limitation: Auto-detection adds latency on short strings, and quality still drops on heavily code-mixed slang.
• Recommendation: Never call api.sarvam.ai directly from the browser. Proxy it, always.

Architecture: Why You Need a Proxy Layer

The request flow is linear, but skipping the proxy is the single most common mistake developers make with this API.

Browser sends input text to your Node.js server, which holds the api-subscription-key. Your server forwards the request to the Sarvam Mayura API at api.sarvam.ai/translate. Translated text returns through the same chain back to the browser.

The key never leaves your server. That is the entire point of this architecture, not performance, not caching, just credential isolation.

Step-by-Step: Building the Translation Integration

1. Understand the Core API Spec

The Mayura endpoint takes three required fields:

• input: the source text, raw string
• source_language_code: "auto" triggers Sarvam's language ID model
• target_language_code: a locale code like hi-IN, ta-IN, or bn-IN

Authentication is a single header: api-subscription-key.

2. Build the Server-Side Proxy

Your Node server intercepts the request, attaches the key from an environment variable, and forwards it:

if (url === '/api/translate' && method === 'POST') {
try {
const body = await getRequestBody(req);
const apiResponse = await fetch('https://api.sarvam.ai/translate', {
method: 'POST',
headers: {
'api-subscription-key': process.env.SARVAM_API,
'Content-Type': 'application/json'
},
body: JSON.stringify(body)
});
const data = await apiResponse.json();
res.writeHead(apiResponse.status, { 'Content-Type': 'application/json' });
res.end(JSON.stringify(data));
} catch (error) {
res.writeHead(500, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ error: 'Translation Proxy failed', details: error.message }));
}
}

Notice the key lives in process.env.SARVAM_API, never in a request body or frontend bundle. If you have not set up environment variables correctly in a Node project before, that is worth getting right before you touch this endpoint.

3. Wire Up the Frontend

The client only ever talks to your own /api/translate route, never Sarvam directly:

async function runTranslation() {
const text = document.getElementById('translate-input').value.trim();
const targetLang = document.getElementById('translate-lang').value;
const resultDiv = document.getElementById('translate-result');
if (!text) return;
resultDiv.textContent = 'Translating...';
try {
const response = await fetch('/api/translate', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
input: text,
source_language_code: 'auto',
target_language_code: targetLang
})
});
const data = await response.json();
if (!response.ok) throw new Error(data.message);
resultDiv.textContent = data.translated_text;
} catch (error) {
resultDiv.textContent = Error: ${error.message};
}
}

4. Tune the Parameters That Actually Matter

source_language_code: "auto" is convenient but not free, since it runs a separate identification pass before translation, which adds measurable latency on short inputs under 10 words. If you already know the source language, hardcode it and skip detection entirely.

target_language_code supports all 22 scheduled Indian languages. Test your specific pair before shipping, since quality is not uniform across all 22.

The Better Way vs The Worst Way

The worst way is calling api.sarvam.ai/translate directly from client-side JavaScript with the key inlined in a fetch call. It works in a demo. It gets your key scraped and rate-limited within a day of going to production.

The better way is exactly the proxy pattern above: key in process.env, server-side fetch, zero credential exposure to the browser. It costs you one extra network hop. That hop is the cheapest insurance you will buy this sprint.

My Take

Every translation API problem in India comes down to one thing: code-mixing, not vocabulary. Hindi-English-Hinglish blended in a single sentence breaks generic models trained on clean monolingual corpora, and that is the actual reason Sarvam exists as a category rather than a feature request to Google. Best case, a proxy like this becomes the backbone of a regional-language SaaS product that Big Tech has not bothered to serve well. Worst case, teams skip the proxy layer entirely, ship the key to the browser, and discover their bill and their rate limit both got hit by a scraper within a week. Right now the entire Indian AI stack, Sarvam, Bhashini, Krutrim, is racing to own regional language infrastructure before OpenAI or Google decide it is worth the effort. Whoever wins that race is not the best model, it is whoever ships the most boring, reliable proxy layer developers actually trust with production traffic.

Comparison Table: Sarvam Mayura vs Alternatives

Feature | Sarvam Mayura | Google Cloud Translate | Bhashini
Indian script coverage | 22 languages, code-mix aware | Broad but generic | Government-backed, 22+ languages
Auto language detection | Yes, built-in | Yes | Partial
Code-mixed / Hinglish handling | Strong | Weak | Moderate
Pricing model | Pay-per-request, developer-friendly | Enterprise tiered | Free, public infrastructure
Best for | Regional-language SaaS products | General-purpose global apps | Government and public-sector tools

Real Developer Use Case

A two-person team building a regional customer support tool for a Tier-2 city logistics company needed Hindi-Marathi-English translation for WhatsApp-style chat support. Google Translate flattened Marathi idioms into literal, unusable English. Switching the backend to Sarvam Mayura with source_language_code set to "auto" cut manual correction time from roughly 40% of translated tickets down to under 8%, because the model actually understood code-mixed customer messages instead of translating word by word.

Frequently Asked Questions

Is the Sarvam Mayura API free to use?
No, it is a paid, pay-per-request API. Sarvam offers a free tier for testing during development, but production traffic at scale requires a paid subscription key tied to your account.

Can I call the Sarvam Mayura API directly from a React frontend?
Technically yes, but you should not. Doing so exposes your api-subscription-key in the browser's network tab, where anyone can extract and reuse it. Always route through a backend proxy.

Which Indian languages does Mayura support best?
Hindi, Tamil, Bengali, and Marathi show the strongest translation quality currently, since they have the most training data. Less common scripts like Assamese or Odia work but need more manual QA.

How is Sarvam different from Bhashini?
Bhashini is a government-backed, free public infrastructure project. Sarvam is a commercial API with tighter SLAs, better documentation, and stronger handling of informal, code-mixed text common in real chat applications.

Does auto language detection slow down translation?
Yes, marginally. Detection adds a small latency overhead, most noticeable on inputs under 10 words. If your source language is fixed and known, hardcode it instead of using "auto".

Conclusion

Use the Sarvam Mayura API when your product needs real Indian regional language translation, not just Hindi-as-an-afterthought support. Developers building for Indian users, especially chat and support tools, should default to this over generic translation APIs. The one takeaway: build the proxy first, test the language pair second, ship the frontend last.

Related reads: How to Use Environment Variables in Next.js (/blog/how-to-use-environment-variables-nextjs) and Best AI Coding Tools for Developers 2026 (/blog/best-ai-coding-tools-developers-2026)