Skip to main content
This page covers the differences between the /v2/languages endpoint and the v3 endpoints, and how to update your integration.
Only GET requests are supported on the v3 endpoints. Unlike /v2/languages, POST is not supported.

​
What changed

​
Single endpoint for source and target

v2 uses a single endpoint with a type query parameter to distinguish source from target: 
GET /v2/languages?type=source
GET /v2/languages?type=target
v3 uses a single endpoint that returns all languages for a product, with each language indicating whether it is usable as a source, a target, or both: 
GET /v3/languages?product=translate_text

​
New product identifiers

v2 languages are implicitly tied to text and document translation. v3 introduces an explicit product parameter that applies across all DeepL API products:
v2v3 product value
(implicit, text/document translation only)translate_text
(implicit, text/document translation only)translate_document
(separate /v2/glossary-language-pairs endpoint)glossary
(not supported)voice
(not supported)write
The v3 endpoints replace both /v2/languages and /v2/glossary-language-pairs.

​
Features instead of supports_formality

v2 target languages include a boolean supports_formality field. v3 replaces this with a features array that covers additional capabilities per product:
v2 fieldv3 equivalent
"supports_formality": true"features": ["formality"] on the language object
For example, querying languages for text translation: 
curl -X GET 'https://api.deepl.com/v3/languages?product=translate_text' \
--header 'Authorization: DeepL-Auth-Key [yourAuthKey]'
Example response (truncated)
[
  {
    "lang": "de",
    "name": "German",
    "usable_as_source": true,
    "usable_as_target": true,
    "features": ["formality", "tag_handling", "glossary"]
  },
  {
    "lang": "en-US",
    "name": "English (American)",
    "usable_as_source": false,
    "usable_as_target": true,
    "features": ["tag_handling", "glossary"]
  }
]
The response indicates German supports formality, but English (American) does not. See the overview for the full list of features per product.

​
Response field names

v2 fieldv3 field
languagelang
namename (unchanged)
supports_formalityfeatures["formality]

​
Language code casing

v2 returned language codes in non-standard casing (e.g. EN-US, ZH-HANT). v3 returns codes compliant with BCP 47: lowercase base language (en, de), uppercase region subtag (en-US, pt-BR), and title-case script subtag (zh-Hant). DeepL accepts language codes case-insensitively as input across all endpoints. However, if your integration stores or compares codes returned by /v2/languages, update those comparisons to be case-insensitive or to expect the new casing.

​
Migrating glossary language pair queries

If you currently use /v2/glossary-language-pairs to discover which language pairs are supported for glossaries, use one of the following:
  • GET /v3/languages?product=glossary to check which languages support glossary management (i.e. creating a glossary for that language). Filter by usable_as_source and usable_as_target as needed. Any combination of a valid source and target language is a supported glossary language pair.
  • GET /v3/languages?product=translate_text to check which languages support using a glossary during text translation. Languages that include "glossary" in their features array support the glossary_id parameter on the translate endpoint.
  • Similarly, use product=translate_document to check glossary support for document translation.