Validate the code to ensure compliance with API deprecation rules regarding GET requests and the use of API keys in the query string

View issue · Add comment

Issue created

slauriere created this issue on 04/Feb/25 16:44

Summary:	Validate the code to ensure compliance with API deprecation rules regarding GET requests and the use of API keys in the query string
Issue Type:	Task
Affects Versions:	1.2
Assignee:	Unassigned
Created:	04/Feb/25 16:44
Priority:	Major
Reporter:	slauriere
Description:	DeepL announced the deprecation of some features in the API. This task is to evaluate the impact of these deprecations on the application and to take action if needed. We're writing to inform you that DeepL plans to deprecate two rarely-used API features. The changes will go into effect on or after March 14, 2025. If you use either feature, you will need to update your application before this date to continue using the DeepL API. 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. 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. Going forward, the /translate endpoint will reject any GET request. Similarly, it will reject a request made with a URL and query string, like this: deprecation-email-example-URL 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 named Authorization, like this: Authorization: DeepL-Auth-Key [yourAuthKey] 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.

5 updates

Changes by slauriere on 04/Feb/25 16:46

Fix Version:	1.2.1
Description:	DeepL announced the deprecation of some features in the API. This task is to evaluate the impact of these deprecations on the application and to take action if needed. {quote} We're writing to inform you that DeepL plans to deprecate two rarely-used API features. The changes will go into effect on or after March 14, 2025. If you use either feature, you will need to update your application before this date to continue using the DeepL API. 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. 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. Going forward, the /translate endpoint will reject any GET request. Similarly, it will reject a request made with a URL and query string, like this: deprecation-email-example-URL 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 named Authorization, like this: Authorization: DeepL-Auth-Key [yourAuthKey] 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. {quote} Detailed announcement: https://developers.deepl.com/docs/resources/breaking-changes-change-notices/march-2025-deprecating-get-requests-to-translate-and-authenticating-with-auth_key
Assignee:	slauriere
Resolution:	Done
Status:	Open Closed

1 comment

slauriere on 04/Feb/25 16:51

The Machine Translation extension in version 1.2 depends on the client library deepl-java 1.5.0 and uses exclusively this library for any translation action. The DeepL announcement mentions that deepl-java 1.0.0+ is not negatively affected by the breaking changes. This means there is no need to update the dependency nor to change the code of the extension.

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-java: 1.0.0+

deepl-php: 1.0.0+

deepl-python: 1.0.0+

deepl-dotnet: 1.0.0+

deepl-node: 1.1.0+

deepl-rb: 3.0.0+

This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)

If image attachments aren't displayed, see this article.