In short, API internationalization support is essential for any API intended for a multi-market audience. It future-proofs your service, making it easy to add languages later and giving a consistent interface worldwide.
x-am-internationalization
to tell API Maker which language to use.x-am-internationalization: Hindi
, API Maker will automatically pull messages from the Hindi language pack and return the correct translations.In short, API Maker’s i18n makes it super easy to build multilingual APIs, right out of the box. Just configure your language packs, and you’re ready to go global.
"Please provide name." → "कृपया नाम प्रदान करें।"
in Hindi.
Once set, all API messages—like errors—will automatically use these translations.x-am-internationalization header
.
So if you use x-am-internationalization: Spanish
, API Maker will return all available messages in Spanish.There’s a built-in “Default” language catalog that acts as a fallback. So even if a message isn’t translated in a selected language, API Maker will still show it in English instead of breaking or showing an error. This makes sure your app works smoothly, even if some translations are missing.
No need to restart your server or project, the updates apply live as soon as you save them.
{
"code": 400,
"message": "Please provide id param value"
}
{
"code": 400,
"message": "कृपया आईडी पैरामीटर का मान प्रदान करें."
}
{
"code": 400,
"message": "请提供id参数的值"
}
{
"code": 400,
"message": "Proporcione el valor del parámetro id."
}
{
"code": 400,
"message": "id パラメータの値を入力してください"
}
{
"code": 400,
"message": "براہ کرم id پیرامیٹر کی قدر فراہم کریں۔"
}
Feature | API Maker | Supabase | Appwrite | Firebase |
---|---|---|---|---|
Built-in i18n Support | ✅ Yes – Full support for multilingual API responses & errors | ❌ No built-in i18n | ⚠️ Limited – Manual i18n in functions/UI only | ⚠️ Limited – Client-side i18n only |
Localized Error Responses | ✅ Yes – Automatic translation of error messages via x-am-internationalization header |
❌ No – Requires manual implementation | ⚠️ Partial – Must handle manually via functions | ❌ No – Developers handle messages on frontend |
Language Selection via Header | ✅ Yes – Use x-am-internationalization to return localized content |
❌ No | ❌ No | ❌ No |
Supports System & 3rd Party Errors | ✅ Yes – Even 3rd-party API errors can be localized | ❌ No | ❌ No | ❌ No |
Dynamic Translation Updates | ✅ Yes – Update translations anytime, no server restart | ❌ No native support | ⚠️ Via function redeploys | ⚠️ Manual in Firestore/functions |
Admin UI for Language Packs | ✅ Yes – Easy setup in dashboard (add Hindi, Spanish, etc.) | ❌ No | ❌ No | ❌ No |
Just go to the Admin UI → Settings → Internationalization. Click “Add Internationalization” to create a new language (like Hindi, French, etc.). Then, add your messages as key-value pairs—like "User not found." → "Utilisateur introuvable."
. That’s it. No server restart needed. Changes work instantly.
If you need native, out-of-the-box support for multi-language responses (especially error messages), API Maker leads the way. Unlike Supabase or Appwrite, where you need to build translation layers manually, API Maker has i18n built in—with zero-code config, runtime switching, and admin UI support. GraphQL doesn't even handle i18n natively, you have to manually build resolvers or externalize strings.
x-am-internationalization
do?It's a special request header. Just set it to the name of your language pack (e.g., "x-am-internationalization: Hindi"
), and your API will respond with error messages in that language.
Accept-Language
header instead?By default, API Maker uses x-am-internationalization
. But yes, you can build a custom hook to read Accept-Language
and map it to your language packs. It’s flexible—you’re in control.
Don’t worry, API Maker automatically falls back to the default language (usually English). Just make sure you always have a default catalog set up for each message. That way, nothing breaks.
Because it just works. It’s fast, flexible, and designed for global teams from day one. Add languages in seconds, switch on the fly, and keep your API logic clean. No hacks. No boilerplate. Just scale-ready i18n that makes developers (and users) happy.
Nope. Changes show up right away. Just save the updates in the admin panel, and your API will start using the new messages immediately. Superfast, zero downtime.
Absolutely. API Maker can also localize field names, labels, and other custom messages.
Yes! API Maker supports emojis, Unicode, and all kinds of scripts, Hindi, Arabic, Chinese, you name it. It’s built for global content.
x-am-internationalization
header to return responses in any language. This greatly simplifies creating multi-language APIs. By enabling i18n, you ensure that error messages and outputs are understandable to a global audience, and you lay the groundwork for seamless localization. The benefits speak for themselves – wider market reach, happier users, and a more maintainable codebase. If you haven’t already, consider enabling and configuring i18n in your API Maker projects today to start building truly international APIs.