Retrieve supported languages by product [BETA]

API reference for retrieving supported languages with the DeepL API across all products.

Get information about all currently supported languages across all DeepL API products.

The /v3/languages endpoints provide a single source of truth for language and feature support across all DeepL API products. They replace the /v2/languages and /v2/glossary-language-pairs endpoints.

If you’re currently using /v2/languages or /v2/glossary-language-pairs, see the migration guide for a full list of differences and code examples.

These endpoints are available for testing in BETA. Breaking changes may be pushed with little or no advance notice, and we provide no guarantees of stability. Please do not use /v3/languages in production. See the changelog for planned changes.

We also provide auto-generated API specs from DeepL’s OpenAPI file, for use with API clients and code generation tools:

• Retrieve languages
• Retrieve products

To understand how we’ll update these endpoints when we add translation support for a new language or language variant, please see this article.

Products list

To retrieve language support, decide which DeepL product you’re building for, then call GET /v3/languages with the appropriate product value. The product parameter is required and identifies which DeepL API product you are querying language support for:

Value	Description
translate_text	Text translation via the /v2/translate endpoint
translate_document	Document translation via the /v2/document endpoint
voice	Speech transcription and translation via the /v3/voice endpoints
write	Text improvement via the /v2/write endpoints
glossary	Glossary management via the /v2/ and /v3/glossaries endpoints

glossary is a product value indicating glossaries can be created for that language, and managed via the glossary management endpoints.

Support for glossaries within specific products (for example text translation) is indicated by the glossary feature value, explained in a later section.

Basic example

Each language in the response includes a features array indicating which optional capabilities are available for that language — see the Product features section below for details.

The examples below use our API Pro endpoint https://api.deepl.com. If you’re an API Free user, remember to update your requests to use https://api-free.deepl.com instead.

The following example responses are truncated; the full API responses can include over 100 languages.

cURL

Example request: languages for text translation

curl -X GET 'https://api.deepl.com/v3/languages?product=translate_text' \
--header 'Authorization: DeepL-Auth-Key [yourAuthKey]'

HTTP Request

Example request: languages for text translation

GET /v3/languages?product=translate_text HTTP/2
Host: api.deepl.com
Authorization: DeepL-Auth-Key [yourAuthKey]
User-Agent: YourApp/1.2.3

Example response

[
  {
    "lang": "de",
    "name": "German",
    "usable_as_source": true,
    "usable_as_target": true,
    "features": [
      "formality",
      "tag_handling",
      "glossary"
    ]
  },
  {
    "lang": "en",
    "name": "English",
    "usable_as_source": true,
    "usable_as_target": false,
    "features": [
      "tag_handling",
      "glossary"
    ]
  },
  {
    "lang": "en-US",
    "name": "English (American)",
    "usable_as_source": false,
    "usable_as_target": true,
    "features": [
      "tag_handling",
      "glossary"
    ]
  }
]

Language codes

Language codes in the lang field follow BCP 47. The base language subtag is always present; script, region, and variant subtags are included where needed to distinguish variants. See Language codes follow BCP 47 for details.

Product features

Each language object includes a features array indicating which optional capabilities are supported for that language with the requested product.

To use a feature, one or both languages in the pair must support it. For example, for text translation:

• Target-only: formality only needs to be supported by the target language. Check that "formality" is present in the target language’s features array.
• Source-and-target: tag_handling and glossary must be supported by both languages. Check that the feature is present in both the source and target language’s features arrays.

Source-only features are also supported by the schema, and may be introduced in future products.

In the documentation for API features that are supported for only a subset of languages, we specify which language feature value to check, and whether to check the source language, target language, or both.

Retrieving products programmatically

Use the /v3/languages/products endpoint to retrieve the list of products and their features programmatically. For each feature, the response indicates which languages must support it for the feature to be available — source only, target only, or both — allowing clients to determine feature availability for a language pair by checking the appropriate features arrays.

curl -X GET 'https://api.deepl.com/v3/languages/products' \
--header 'Authorization: DeepL-Auth-Key [yourAuthKey]'

Example response (truncated)

[
  {
    "name": "translate_text",
    "endpoints": ["v2/translate"],
    "features": [
      {
        "name": "formality",
        "required_on_target": true
      },
      {
        "name": "custom_instructions",
        "required_on_target": true
      },
      {
        "name": "tag_handling",
        "required_on_source": true,
        "required_on_target": true
      },
      {
        "name": "glossary",
        "required_on_source": true,
        "required_on_target": true
      }
    ]
  }
]

API stability

The v3 language endpoints are designed to be forward-compatible:

• New features may be added to the features array
• New languages will be added as DeepL support expands
• Existing fields will not be removed or changed in backwards-incompatible ways

Build your integration to gracefully handle new BCP 47 lang codes and new values in the features array. Do not hardcode assumptions about the format of language codes — see Language codes follow BCP 47 for details.

Best practices

1. Cache responses: Language support changes infrequently. Consider caching responses for up to 1 hour.

2. Check features: Always check the features array on language objects rather than assuming support (e.g. for formality, glossary use, or writing style).

3. Handle forward compatibility: New languages and features may be added at any time. Build your integration to dynamically accept new lang codes and features values instead of maintaining a hardcoded allowlist.

4. Use specific variants: For target languages, prefer specific regional variants (e.g., "en-US", "en-GB") when the distinction matters to your users.