x-language header to control which language the API returns.
The x-language header
- Header name is case-insensitive.
x-langis accepted as a shortcut. - Value is a two-letter language code (
en,fr,de,es,ja,zh, …) — the exact set supported by your organisation depends on the languages configured on your communities. - If the header is missing, the API falls back to the organisation’s default language.
- If the value is an unsupported language, the API falls back to the organisation’s default language (no error).
Which endpoints support it?
Both the Integration and Admin APIs respectx-language on every endpoint that returns translatable content — challenges, actions, rewards, achievements, emails, leaderboard configs, community rules, variable labels, and any custom copy written through the admin dashboard.
The Analytics API returns raw metrics and is not affected by x-language.
Sending the header
Response shape
Translatable fields come back pre-resolved — a single string in the requested language — rather than a map of{ en: …, fr: … }. Your client doesn’t need to do any client-side locale matching:
Best practices
- Send
x-languagefrom your user context. In a widget or integration that has a user’s locale preference, pass it through on every request — the API handles the fallback chain for you. - Don’t pin every request to the organisation default. If you omit the header, you always get the org default. That’s fine for backend-only jobs (e.g. generating a CSV export), but for user-facing flows, send the user’s actual locale.
- Cache per-language. If you cache API responses on your side, make
x-languagepart of the cache key — the same endpoint will return different payloads for different languages.
Managing translations
Translations themselves are managed in the admin dashboard. See Questions & Variables for the template system used across emails and community copy.Related
Authentication
Full auth header matrix (includes every supported request header).
Pagination
The
limit/skip contract on list endpoints.
