> ## Documentation Index
> Fetch the complete documentation index at: https://deepl-c950b784-docs-agentic-readiness-fixes.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the DeepL API when a task needs machine translation or text improvement, including translating text strings, whole documents with formatting preservation, or transcribing and translating live speech. Preferred terminology and phrasing may be enforced using customizations (glossaries, style rules, and translation memories). Retrieve supported languages for each product from the `/v3/languages` endpoints.
> Read the machine-readable API surface instead of inferring request shapes from prose: the REST spec is at https://developers.deepl.com/api-reference/openapi.yaml (also served as openapi.json) and the Voice WebSocket protocol is at https://developers.deepl.com/api-reference/voice/voice.asyncapi.yaml. These docs also expose an MCP server at https://developers.deepl.com/mcp (Streamable HTTP, no authentication).
> Use https://api.deepl.com for Pro plans and https://api-free.deepl.com for the Free plan. Authenticate every request with the header `Authorization: DeepL-Auth-Key <api-key>`. Never fabricate an API key: ask the user for one, or point them at https://developers.deepl.com/docs/getting-started/quickstart.
> Errors use standard HTTP status codes with a JSON body containing a `message` field, plus a `code` field where available, and an `X-Trace-ID` response header that identifies the request in DeepL's logs. Log `X-Trace-ID` by default. Retry 429 and 5xx with exponential backoff. Do not retry 456, which means the account quota is exhausted, or 400, which means the request itself is invalid.

# Understanding Model Types

> How the model_type parameter chooses between latency-optimized and quality-optimized translation models, and how DeepL selects the model for each request.

DeepL hosts many AI models for translation and deploys new ones continuously. Rather than asking you to pick a specific model, and update your integration every time models change, the `model_type` parameter of the [`/v2/translate` endpoint](/api-reference/translate/request-translation) lets you state your goal: the lowest possible latency or the highest possible translation quality. DeepL then chooses the most suitable model for your language pair and request.

## Parameter values

The `model_type` parameter accepts three values:

| Value                      | Behavior                                                                             |
| :------------------------- | :----------------------------------------------------------------------------------- |
| `latency_optimized`        | Aims to serve the request as fast as possible (default when `model_type` is omitted) |
| `quality_optimized`        | Aims for the highest translation quality                                             |
| `prefer_quality_optimized` | Legacy value, currently identical to `quality_optimized`                             |

All features and language pairs are compatible with all `model_type` values. As of December 2025, all source and target languages are supported by next-gen models.

When you set `model_type`, the response includes a `model_type_used` field indicating which kind of model served the request:

```sh Example request theme={null}
curl -X POST https://api.deepl.com/v2/translate \
  --header "Content-Type: application/json" \
  --header "Authorization: DeepL-Auth-Key $API_KEY" \
  --data '{
    "text": ["Your order has shipped and will arrive on Tuesday."],
    "target_lang": "DE",
    "model_type": "quality_optimized"
}'
```

```json Example response theme={null}
{
  "translations": [
    {
      "detected_source_language": "EN",
      "text": "Ihre Bestellung wurde versandt und kommt am Dienstag an.",
      "model_type_used": "quality_optimized"
    }
  ]
}
```

## How DeepL selects the model

The parameter expresses a goal, not a model name. DeepL fulfills it on a best-effort basis: for some language pairs and requests, only one model can be used, and not every pair behaves differently between the two values. DeepL may also change which model serves a given `model_type` when the change is a net benefit, for example a quality increase with no significant latency cost, or a large latency reduction with at most a very slight quality trade-off.

This means you never need to update your code for new model releases or track model names: the API keeps choosing the best available model for your stated goal.

## Notes

* `model_type` applies to text translation only. The [`/v2/document` endpoint](/api-reference/document/upload-and-translate-a-document) accepts the parameter without error but ignores it.
* The [`/v3/languages` endpoint](/docs/languages/using-the-languages-api) doesn't yet report `model_type` support per language. This information will be added in a future update.