Switching from DeepL

Ще не перекладено — показано англійською.

The request and response formats are deliberately compatible with DeepL's v2 text API. In most codebases the migration touches configuration, not code.

What changes

SettingDeepLLanguage API
Base URLhttps://api.deepl.com/v2 or https://api-free.deepl.com/v2https://api.langapi.xyz/v1
Keyxxxxxxxx-xxxx-...:fxla_live_xxxxxxxx
Auth headerAuthorization: DeepL-Auth-Key <key>Same header accepted; Authorization: Bearer <key> preferred

There is one host for all plans and both key modes. Free and paid traffic are not split across different domains.

Official client libraries

Because the DeepL-Auth-Key header is honoured, the DeepL client libraries work with only the server URL changed.

Python:

import deepl

client = deepl.Translator(
    "la_live_xxxxxxxx",
    server_url="https://api.langapi.xyz/v1",
)
result = client.translate_text(
    "Your session has expired. Please sign in again.",
    source_lang="EN",
    target_lang="SV",
)
print(result.text)

Node:

import * as deepl from 'deepl-node';

const client = new deepl.Translator('la_live_xxxxxxxx', {
  serverUrl: 'https://api.langapi.xyz/v1',
});
const result = await client.translateText(
  'Your session has expired. Please sign in again.',
  'en',
  'sv',
);
console.log(result.text);

Raw HTTP with the DeepL header and a form body:

curl https://api.langapi.xyz/v1/translate \
  -H "DeepL-Auth-Key: la_live_xxxxxxxx" \
  --data-urlencode "text=Your session has expired. Please sign in again." \
  --data-urlencode "target_lang=SV"

Compatibility matrix

FeatureStatus
POST /translate with text, target_lang, source_lang, formality, glossary_id, tag_handling, preserve_formatting, contextIdentical
text as repeated form field or JSON arrayIdentical
translations[].text and translations[].detected_source_languageIdentical
GET /languages?type=source and ?type=target with supports_formalityIdentical
GET /usage with character_count and character_limitIdentical, with a billing object added
Glossary create, list, get, entries, delete and /glossary-language-pairsIdentical, tab-separated entries accepted
Regional codes EN-GB, EN-US, PT-PT, PT-BRIdentical
formality: prefer_more / prefer_lessSupported
split_sentencesNot supported; splitting is internal
outline_detectionNot supported
Document translation (/document)Not available
Glossary updateNot available; glossaries are immutable

Differences you may need to handle

  • Error bodies. Errors are RFC 9457 problem documents with a stable

code field rather than {"message": "..."}. Code that inspects DeepL's message strings must switch to code. See Error codes reference.

  • Additional response data. The translate response includes request_id,

characters and an engine token object. The headers X-Request-Id, X-Characters-Billed and X-RateLimit-* are new. Clients that ignore unknown fields are unaffected.

  • Free usage. Instead of a separate free host, a verified account receives

credit for 100,000 characters on the regular host.

  • Strict formality. more and less on a target without formality

support answer 400, as with DeepL. The prefer_ variants avoid that.

Cutover checklist

  1. Create a la_test_ key and point staging at the new base URL.
  2. Run the translation tests you already have. Failures here are genuine

incompatibilities, not quality differences.

  1. Translate a sample of real production strings through both providers and

have someone who reads the target language compare them.

  1. Switch production. Leave the previous configuration in place for a week so

that reverting is a config change.

  1. Revoke keys you no longer need, on both sides.

Comparing cost

Both providers charge per source character including whitespace and markup, so the comparison is a multiplication. Take the character volume from a recent invoice and enter it on the pricing page. Note that cache hits are charged here, so a workload with a high repeat rate should be estimated with its full volume.

Оновлено 7 вер. 2026 р., 00:00