API Maker Internationalization | i18N Support

Auto Generated APIs

Easily adapt your app for any language, region, or culture with powerful internationalization support.

  • Internationalization, or i18n, means building software in a way that it can easily support different languages and cultures. For APIs, this mainly involves making sure that things like error messages and responses can be translated based on the user’s language. With i18n, you don’t need to change your code for every language—you just provide translated versions of your messages, and the API automatically uses the right one for each user.
  • API Maker Internationalization: Multiple Language Support For Error Messages

Want to make your APIs multilingual without breaking a sweat?

  • Getting error message in user specific language is challenging task to handle by backend developer. API Maker makes developer life easy by providing it out of the box.
  • API Maker’s built-in internationalization (i18n) lets developers send API responses in the user’s preferred language. All you need to do is add a language code in the request header, and the API will return messages—like errors or responses—in that language. This makes it easy to create multilingual APIs that are ready for global users from the start.

Why Internationalization Matters in API Development?

  • You can enter new markets quickly by offering localized responses, “increasing your consumer base” and user satisfaction. Users see content in their own language, which boosts adoption and trust.
  • Localized APIs help your frontend and mobile apps feel like they truly belong in the user’s language and region. They improve the overall user experience, making users feel more comfortable and understood. Plus, i18n gives you a competitive edge when expanding into global markets.
  • With internationalization (i18n), you only need one codebase to support all languages and regions. All your language strings are stored in one place, so it’s easy to update or manage them without touching the core code. This means no duplicate logic for each language—just clean, centralized control.
  • With i18n, translators don’t need to dig into your code, they work with text keys instead. This makes the translation process faster, cheaper, and easier because everything is managed as data, not hardcoded into the app.

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.


Internationalization in API Maker

  • API Maker has built-in support for internationalized responses and error messages. You just need to create a language entry (like "English" or "Hindi") in the admin panel. Then, in your API request, use the header x-am-internationalization to tell API Maker which language to use.
  • Once set, API Maker automatically returns error messages in that language—whether it's a system error, a custom API error, or even a third-party API error.
  • For example, if your request includes x-am-internationalization: Hindi, API Maker will automatically pull messages from the Hindi language pack and return the correct translations.
  • You can add as many languages as you want—like English, Hindi, Spanish, etc.. and even update translations instantly without restarting your server. Switching languages takes just seconds.
  • You can override English error messages of system in English and multiple times also means we can have multiple English language translations based on user region and choice.
  • It also supports converting database fields in to user specific language and dynamically place them in generated error.

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.

  • You can add as many languages as you need. Each language pack maps your original message keys to translated text. For example: "Please provide name." → "कृपया नाम प्रदान करें।" in Hindi. Once set, all API messages—like errors—will automatically use these translations.
  • Clients just send the desired language using the x-am-internationalization header. So if you use x-am-internationalization: Spanish, API Maker will return all available messages in Spanish.
  • If no language is specified in the request (or if the requested language isn’t available), API Maker automatically uses a default language, usually English.

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.

  • You can update translations instantly in API Maker. Just go to the admin console, add or edit a message, and the change will show up right away.

No need to restart your server or project, the updates apply live as soon as you save them.

  • API Maker lets you use any kind of characters in your translations, including symbols, emojis, and scripts like Hindi, Chinese, Arabic, and more. It fully supports Unicode, so your messages can look exactly how you want in any language.

Examples

  • Default error response ["x-am-internationalization": "Default"]
{
    "code": 400,
    "message": "Please provide id param value"
}
  • response in Hindi language ["x-am-internationalization": "Hindi"]
{
    "code": 400,
    "message": "कृपया आईडी पैरामीटर का मान प्रदान करें."
}
  • response in Chinese(Simplified) language ["x-am-internationalization": "Chinese simple"]
{
    "code": 400,
    "message": "请提供id参数的值"
}
  • response in Spanish language ["x-am-internationalization": "Spanish"]
{
    "code": 400,
    "message": "Proporcione el valor del parámetro id."
}
  • response in Japanese language ["x-am-internationalization": "Japanese"]
{
    "code": 400,
    "message": "id パラメータの値を入力してください"
}
  • response in Urdu language ["x-am-internationalization": "Urdu"]
{
    "code": 400,
    "message": "براہ کرم id پیرامیٹر کی قدر فراہم کریں۔"
}

API Maker’s internationalization doesn’t just translate error messages, it can also translate field names into multiple languages.

  • This means when error comes that database field name will be converted into i18N.

🔍 Internationalization (i18n) Feature Comparison

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

FAQ's

1. How can I add or update translations in API Maker?

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.

2. Is API Maker better than Supabase, Appwrite, or GraphQL for i18n?

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.

3. What does 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.

4. Can I use the normal 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.

5. What happens if a translation is missing?

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.

6. So, why is API Maker the best for international APIs?

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.

7. Do I need to restart the server after adding new translations?

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.

8. Can API Maker translate more than just error messages?

Absolutely. API Maker can also localize field names, labels, and other custom messages.

9. Can I use emojis or non English scripts in translations?

Yes! API Maker supports emojis, Unicode, and all kinds of scripts, Hindi, Arabic, Chinese, you name it. It’s built for global content.


Internationalization is a critical feature for any modern API that serves users across different regions. With API Maker’s built-in i18n support, you get API internationalization support out of the box: just configure your languages, and use the 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.


Error Message