Retrieves all system-supported languages and localization settings

GET /api/configuration/system/allowed-languages

Success: 200 OK

Products: Operator (FOH), Consumer (CONSUMER) (any one of these products, not all)
Features: Online Bookings (ONLINEBOOK), Online Joining (ONLINEJOIN), Front of House Generic Access (FOHGENERIC) (any one of these features, not all)

Overview

Lists the languages this environment has been switched on for — the set an operator has opted into, not the set the platform is capable of. Use it to decide which language options to offer a member, and which cultures are worth requesting from the translation-bearing endpoints.

The list is derived from configuration: the environment holds a single configuration setting, Cultures_AllowedLanguages, containing comma-separated language codes, and this endpoint resolves each code against the platform's list of known languages and returns the ones it recognises. Two consequences follow.

Codes in the setting that do not match a known language are silently dropped. You get back fewer entries than the setting names, with no error and nothing to indicate a mismatch.
Nothing here is per-site. The setting is read at environment scope, so this endpoint returns one answer for the whole tenant even though the underlying configuration supports site overrides. If a site has been given its own language list, this endpoint will not show it.

A 200 with an empty array does not necessarily mean "no languages". When the Cultures_AllowedLanguages setting cannot be read at all, the endpoint returns an empty list rather than an error — so an empty response means either "genuinely none configured" or "the configuration lookup failed", and you cannot tell which from the response. Treat an unexpected empty array as a fault to investigate, not as a valid state to build on.

For the platform's full language list rather than this environment's subset, use Get all available cultures.

Endpoint

GET {base_url}/api/configuration/system/allowed-languages

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Sample request

cURL

curl -X GET '{base_url}/api/configuration/system/allowed-languages' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`[].code`	string	The language code, in IETF language-and-region form — the codes shipped with the platform are `en-GB`, `cy-GB` and `en-IE`, and an operator's environment may add more. Maximum 40 characters and never null. This is the value to match against the `culture` field on translated records, such as the `translations` returned with site amenities and facilities; matching is case-insensitive throughout the platform, so do not depend on the casing you receive. Returned in whatever order the language table yields, not in the order the configuration setting lists them.
`[].name`	string	The language's English display name — for example `English`, `Welsh` — up to 255 characters and never null. It is the platform's own label, not a localised endonym, so do not present it as the option text in a language picker without checking that it reads correctly to a speaker of that language.

Sample response

200 OK

[
  {
    "code": "string",
    "name": "string"
  }
]

Errors

Status	Meaning	When
`200`	OK	Success. Also returned, with an empty array, when the `Cultures_AllowedLanguages` setting could not be read — the failure is logged rather than surfaced, so an empty array is ambiguous.
`500`	Internal server error	An unexpected server-side failure, in practice a failure reading the platform's language list. The response has no body. Note that a failure to read the configuration setting does not land here; it produces a `200` with an empty array instead.

This page as markdown · All pages · llms.txt