I am currently experiencing an issue with the Umbraco Translation Manager. When creating a translation job, I receive the following error message:
Error creating job: Authorization failure, check AuthKey, message: Wrong endpoint. Use https://api.deepl.com. You can find more info in our docs: https://developers.deepl.com/docs/getting-started/auth
Previously, I had a Free API key configured. However, since we are currently reaching the usage limit, I would like to switch to a Pro account and use the corresponding API key.
My question is: does the Translation Manager automatically detect which DeepL version is being used, or does the connector need to be reseted manually somewhere?
If the connector needs to be reset or updated, is there a way to reset the Translation Manager’s configuration without losing my existing settings?
I have already tried updating the package to version 13.0.0, as I am currently using Umbraco 13.
In my experience, you shouldn’t need to reset anything in Translation Manager when switching from a DeepL Free account to a Pro account.
I would first verify that the API key is correct, as DeepL Pro uses a different endpoint than the Free API. Make sure the new Pro API key is entered correctly in the Translation Manager settings and that any old Free API key has been replaced.
The error message suggests that requests are still being sent to the Free endpoint while using a Pro key, so I’d double-check the configured key and connector settings before trying anything more drastic.
As far as I know, there is no need to reset Translation Manager or recreate existing configuration just because you’re moving from Free to Pro.
I don’t think the Free/Pro URL is different anymore (free has sort of been discontinued) - as such we don’t specify the URL in the requests anymore (we use to on the v8 version,
For v13 we also moved to using the official the DeepL.Net nuget library - which i think if there is anything to handle when you change it does it (but i don’t think there is)
@KevinJump: That makes sense, but why doesn’t Deepl handle this in its own NuGet package? That doesn’t make sense. If I switch to the endpoint https://api.deepl.com locally in a short script and use exactly the API key I’ve stored, it works.
Is this a bug on Deepl’s part, or can I override this somehow in the Translation Manager?
Because this is v13, the library we depend on is probably a bit old (but it should still work). you could try directly adding a dependency to DeepL.Net in the project.
I can’t guarantee this will work. there might be breaking changes, but i think the v13 package references v1.7 and the latest is v1.21 - in theory there are no breaking changes.
you could also confirm your key on a test v17 install ? if you have an umbraco v17 site with translation manager v17 (this should add deepl by default) then add the key, this will be using the latest versions of these libraries (as this is the fully supported release)
if the v17 version works, then maybe uping the deepl libary might fix it.