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