Important: The deprecations described on this page apply to both the
v1
(CAT tool) and v2
API versions.Change Notice
On or after March 14, 2025, DeepL will deprecate two little-used API features.- You will no longer be able to send GET requests or query parameters to the
/translate
endpoint. Going forward,/translate
will accept only POST requests with data included in the request body. - You will no longer be able to authenticate a request to any endpoint by sending an API key in a query parameter. Instead, send your API key in an HTTP header named
Authorization
. - If you use one of DeepL’s officially-supported client libraries, you won’t be negatively affected by the breaking changes and do not need to update your application. Specifically, we’ve confirmed the following client library versions:
- deepl-php: 1.0.0+
- deepl-python: 1.0.0+
- deepl-java: 1.0.0+
- deepl-dotnet: 1.0.0+
- deepl-node: 1.1.0+
- deepl-rb: 3.0.0+ (the first version where DeepL took over ownership of the Ruby client library)
Use POST for /translate
Going forward, you will need to send requests to the/translate
endpoint using POST, not GET. This also means you will not be able to send such requests using only a URL. You will need to send data in the request body, not in query parameters.
This example from the documentation shows an HTTP POST request to translate the English sentence “Hello, world!” into German.
Authenticate with an HTTP header
Going forward, you will need to authorize any API request, to any endpoint, by including your API key in an HTTP header namedAuthorization
, like this:
Authorization
header, please see the documentation.
Going forward, you will not be able to authorize any request, to any endpoint, by including your API key in an auth_key
query parameter.
Why is DeepL doing this now?
Use POST for /translate
It is a standard API practice to use GET to request data and POST to send data. To request a translation, one must send data, making POST the customary choice. By disallowing GET and query params for this endpoint, we bring our API in line with industry best practices. Additionally, data sent in query parameters is less secure than data sent in a POST body, as URLs with query parameters may be stored in browser history, discovered in logs, and more. This change helps us make the API more efficient and more private for everyone.Authenticate with an HTTP header
Similarly, the API best practice is to authenticate a request by including the API key in an HTTP header. Sending an API key in a GET request or in a URL risks exposing the API key to the public via logs or other means. For privacy and security reasons, we must disallow this practice.What if I continue to use a deprecated feature?
After the date above, translation requests that use GET or query parameters will fail. Requests to any API endpoint that attempt to authenticate with the oldauth_key
parameter will fail as well.
What action should I take so that I’m not affected?
If you develop your own application using the DeepL API:- Ensure your code is not using either of the deprecated features.
- Update to the most recent version of the plugin. If you experience trouble, contact the plugin provider to make sure they are aware of these deprecations.