Skip to main content
This page shows how to use the /v3/languages endpoints for common integration tasks. Examples are written as pseudocode and are product-agnostic unless otherwise noted. For background on how features and feature dependency types work, see the overview.
The examples below do not account for language pair exceptions. For most integrations this is fine — exceptions are rare and the API handles them gracefully by disabling the unsupported feature rather than failing. If you need precise feature support for specific language pairs, see Handling language pair exceptions at the end of this page.

​
Populate source and target language dropdowns

A single call to GET /v3/languages returns all languages for a product. Filter by usable_as_source and usable_as_target to populate each dropdown separately. 
GET /v3/languages?product=translate_text

languages = response

source_options = languages.filter(l => l.usable_as_source)
target_options = languages.filter(l => l.usable_as_target)

render source_dropdown(source_options)
render target_dropdown(target_options)

​
Show formality options only when supported

formality only needs to be supported by the target language. Check the selected target language’s features array — no need to look at the source language. 
GET /v3/languages?product=translate_text

languages = response
target = languages.find(l => l.lang == selected_target_lang)

if target.features.includes("formality"):
    show formality_selector  // e.g. ["default", "more", "less"]
else:
    hide formality_selector

​
Check if a glossary can be used for a given language pair

glossary must be supported by both languages. 
GET /v3/languages?product=translate_text

languages = response

source = languages.find(l => l.lang == source_lang)
target = languages.find(l => l.lang == target_lang)

glossary_allowed = source.features.includes("glossary")
               and target.features.includes("glossary")

​
List target languages that accept glossaries from a given source language

Filter to targets where both the source and target support the glossary feature. 
GET /v3/languages?product=translate_text

languages = response
source_lang = "en"

source = languages.find(l => l.lang == source_lang)

if not source.features.includes("glossary"):
    return []  // source doesn't support glossary at all

targets_with_glossary = languages
    .filter(l => l.usable_as_target)
    .filter(l => l.features.includes("glossary"))

​
Show writing style options for the Write product

writing_style is a target-only feature on the write product. Check the target language’s features array. 
GET /v3/languages?product=write

languages = response
target = languages.find(l => l.lang == selected_target_lang)

if target.features.includes("writing_style"):
    show writing_style_selector
else:
    hide writing_style_selector

​
Check if style rules are available for a target language

Use product=style_rules to query which languages support style rules. Style rules are target-language only — check that the target language is listed in the response. The style_rules product has no additional features, so only the language availability needs to be checked. 
GET /v3/languages?product=style_rules

languages = response
target = languages.find(l => l.lang == selected_target_lang)

if target and target.usable_as_target:
    show style_rules_selector
else:
    hide style_rules_selector

​
Determine feature support programmatically

Use /v3/languages/products to drive feature checks at runtime — without hardcoding which features need target-only or both-language support into your client. 
GET /v3/languages/products
GET /v3/languages?product=translate_text

products = first response
languages = second response

product = products.find(p => p.name == "translate_text")
source = languages.find(l => l.lang == source_lang)
target = languages.find(l => l.lang == target_lang)

for feature in product.features:
    supported = true
    if feature.required_on_source and not source.features.includes(feature.name):
        supported = false
    if feature.required_on_target and not target.features.includes(feature.name):
        supported = false

​
Handling language pair exceptions

In rare cases, feature support for a specific pair differs from what the individual language objects indicate. The /v3/languages/exceptions endpoint exposes these cases. When an exception exists for a pair, its features array is authoritative — use it directly instead of intersecting the individual language features arrays. The example below shows a full glossary pair check that accounts for exceptions: 
GET /v3/languages?product=translate_text
GET /v3/languages/exceptions?product=translate_text

languages = first response
exceptions = second response

exception = exceptions.find(e => e.source_lang == source_lang && e.target_lang == target_lang)

if exception:
    features = exception.features
else:
    source = languages.find(l => l.lang == source_lang)
    target = languages.find(l => l.lang == target_lang)
    features = intersect(source.features, target.features)

glossary_allowed = features.includes("glossary")
The same pattern applies to any feature check — replace "glossary" with the feature you are checking.