Style rule not found

[oussama-touzni]

Hello , I am using the 1.14 version and I am getting this error , the style rule id is correct ( from the list rules endpoint )
I saw in the documentation (https://developers.deepl.com/api-reference/style-rules)

com.deepl.api.NotFoundException: Not found, check serverUrl, error message: message: Bad request. Reason: Style Rules dd38d218-65f8-492c-b62c-00520a1c5f5e not found at com.deepl.api.Translator.checkResponse(Translator.java:1066) at com.deepl.api.Translator.translateText(Translator.java:207) at tn.ittun.translatordeeplback.service.TranslationService.translateListWithDeepl(TranslationService.java:123) at tn.ittun.translatordeeplback.step.WriteTranslationToDocumentStep.processBatch(WriteTranslationToDocumentStep.java:136) at tn.ittun.translatordeeplback.step.WriteTranslationToDocumentStep.handleStartDocument(WriteTranslationToDocumentStep.java:120)

Clients using the api-us.deepl.com endpoint will not be able to access glossaries or style rules created in the UI at this time.

but I am not sure how to determine which base url is being used ( I don't see api-us in the DeeplClient class )

Can you please help with this issue ?

[BriannaDelgado]

Hello,

The server URL can be set both via the DEEPL_SERVER_URL environmental variable or the DeepLClientOptions setServerUrl() setter. That being said, I don't think that's the underlying cause for your issue since we do not default to api-us.deepl.com in the codebase. Additionally if you could list the rule in via the api-us.deepl.com server url, you should then be able to translate with it using api-us.deepl.com as well.

That being said, I believe the issue might be with the target language. Could you check that the target language that you pass to translateText() is the same as the language for the style rule? We try to look up the style rule based on its id and the target language provided. Therefore if you have a style rule for French but try to translate with that rule to German, we would respond with a 404.

[oussama-touzni]

Hello @BriannaDelgado , thanks for your reply.
For more context : I am creating a new client for each client request ( BYOK app ) , and I am not setting any env var for the URL.
I am also filtering the style rules on my front end depending on the target language
// Handle style rules if (selectedLanguageTo != null) { const languageCode = selectedLanguageTo.toLowerCase(); const matchingStyleRules = styleRules.filter( (rule) => rule.language.toLowerCase() === languageCode );

[BriannaDelgado]

Hi @oussama-touzni - I took a look at our logs for the dd38d218-65f8-492c-b62c-00520a1c5f5e style rule. I can see requests to our text translation API using that style rule from two different accounts. On 12/24, I see requests with the style rule that succeeded succeeded for one account (I believe it's yours based on the email that's in your Github profile). But on 1/4 I can see a different user in another organization tried to translate with that style rule and experienced a 404.

Based on the logs, I think the issue is that the user who experienced the 404 does not have the permissions to access the style rule. Are you certain that the same API key was used for both the listStyleRules() call and the translateText() call?

[oussama-touzni]

Hello Brianna,
in fact it is a customer API key , and yes my plugin loads the styles rules from the API key , filters styles rules by the selected target language and sends the request ( all using the same key )

[BriannaDelgado]

Hi @oussama-touzni,

Upon reviewing our logs, I found that on 1/4, there was a request from the customer to the text translation API at 20:16:33 UTC that received a 404 error. Interestingly, the closest request made by the customer to the get style rules endpoint occurred earlier at 16:42:30 UTC. However, your account made a request to the get style rules endpoint at 20:15:18 UTC, just before the 404 error from the customer. This timing raises some questions regarding whether the customer was indeed the one making the API request at that time.

It's important to note that the dd38d218-65f8-492c-b62c-00520a1c5f5e style rule is associated with your account and not the customer's. Since your account and the customer belongs to two different organizations, it is expected that the customer would not have access to this style rule, which explains the 404 error they encountered. Given the design of our API, it’s fairly unlikely that the GET style rules endpoint would erroneously return the dd38d218-65f8-492c-b62c-00520a1c5f5e style rule for the customer. If the customer is seeing this style rule, are you perhaps caching any style rule data?

If possible, the customer could run the cURL request with their API key to verify if the style rule is in fact in the response.

curl -v --request GET \
  --url 'https://api.deepl.com/v3/style_rules' \
  --header 'Authorization: DeepL-Auth-Key [API-KEY]'