Translator resource returns 401 Unauthorized despite Active status, valid keys, correct config

Question

Translator resource returns 401 Unauthorized despite Active status, valid keys, correct config

Aleksejs Zitkovs 0

Resource "deltamobile-translator" (Cognitive Services, Translator, Free F0 tier, North Europe) shows Status: Active, no suspension, unrestricted networking (All networks). However, all translation requests fail with HTTP 401 (code 401001, "The request is not authorized because credentials are missing or invalid"). Verified extensively before posting: - Both Key1 and Key2 tested directly via API — both return 401 - Tested with and without Ocp-Apim-Subscription-Region header (northeurope, matching resource's configured region) — same 401 either way - Endpoint confirmed correct (api.cognitive.microsofttranslator.com, matches portal's text-translation endpoint shown under Keys and Endpoint) - Networking/firewall confirmed unrestricted (All networks) - Each API response has a unique, fresh x-requestid and comes from server: istio-envoy — confirmed genuine live responses, not cached - The built-in "Try it" tool on the resource's own portal page also fails with "Translation failed. Please try again later." - Resource Health page shows "We were unable to fetch data" for this resource This strongly suggests a backend/service-side issue with this specific resource, not a client-side configuration problem. Has anyone encountered this before, or know what could cause a resource to show Active in the portal while consistently rejecting all requests with 401?

0 comments

1 answer

Your answer

Answer 1

Hello @Aleksejs Zitkovs

You've already ruled out the most common causes of Translator 401001, especially since both Key1 and Key2 fail, the resource is Active, networking allows all networks, and the Azure portal's Try it operation also fails.

For a regional Translator resource such as yours in North Europe, Microsoft documents that key-based requests to the global Translator endpoint should include both:

Ocp-Apim-Subscription-Key: <your-key>
Ocp-Apim-Subscription-Region: northeurope
Content-Type: application/json

For example:

curl -X POST \
"https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&from=en&to=de" \
-H "Ocp-Apim-Subscription-Key: <KEY1>" \
-H "Ocp-Apim-Subscription-Region: northeurope" \
-H "Content-Type: application/json" \
--data-raw '[{"text":"Hello"}]'

The region header is required for a regional Translator resource and optional only for a single-service global resource.

Since you've already tested that configuration, check one more thing before treating this entirely as a backend incident: your F0 usage/quota.

There is a previously documented Microsoft Q&A case where Translator returned the same: "401001 The request is not authorized because credentials are missing or invalid" even though the credentials were correct. In that case, the actual cause was that the user had exhausted the free-tier allowance. Unfortunately, the error message did not identify the quota condition correctly.

Check the Translator resource under Metrics/Usage + quotas and verify whether the F0 character allowance has been exhausted. If possible, you could also temporarily create another Translator resource or move to an appropriate paid tier and run the same minimal request. Don't change the pricing tier solely as a troubleshooting step if that would incur unwanted charges.

If F0 quota is still available, I'd run one additional isolation test using the regional token endpoint:

curl -v -X POST \
"https://northeurope.api.cognitive.microsoft.com/sts/v1.0/issueToken" \
-H "Ocp-Apim-Subscription-Key: <KEY1>" \
-H "Content-Length: 0"

You can exchange regional resource keys through the corresponding regional STS endpoint.

If that request also returns 401, even with a freshly copied/regenerated key, it would be strong evidence that the issue is with the resource's backend authentication/entitlement state rather than your translation request.

Then, open an Azure Support request for Azure Translator / Foundry Tools and provide:

Resource region: North Europe
SKU: F0
HTTP status/error: 401 / 401001
Several x-requestid values
UTC timestamps for those requests
Confirmation that Key1 and Key2 were tested
Confirmation that keys were regenerated
Confirmation that the portal Try it operation also fails
Result from the regional STS issueToken test

Don't post either API key publicly.

Specifically ask Microsoft to verify the Translator resource's backend authentication/entitlement state. An Azure resource showing Active in ARM doesn't by itself prove that its data-plane authentication is functioning correctly.

If you need an immediate workaround and another newly created Translator resource works with the same request, that would further isolate the problem to this specific resource.

References:

Translator authentication and authorization

Authentication in Foundry Tools

Translator REST API v3 reference

Previous Microsoft Q&A case involving 401001 and F0 usage

---

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.