Translator global endpoint returns 401001 for a healthy resource; the resource's own endpoint works

Continue using the resource-specific endpoint in production and open an Azure technical support request for the global-endpoint failure; the evidence isolates the rejection to the global gateway, but no public information confirms the underlying cause or a restoration time.

Supported workaround

Translator supports global, geography-specific, and resource-specific endpoints. Your successful resource-specific request is a supported API pattern, not an unofficial workaround.^1^

curl -X POST \
  "https://<resource>.cognitiveservices.azure.com/translator/text/v3.0/translate?api-version=3.0&to=uk" \
  -H "Ocp-Apim-Subscription-Key: <key>" \
  -H "Ocp-Apim-Subscription-Region: northeurope" \
  -H "Content-Type: application/json" \
  -d '[{"Text":"hello"}]'

Keep the global and resource-specific base URLs configurable so production can remain on the working endpoint without a code deployment when Microsoft resolves the gateway path.

What the results establish

The documented contract for a regional Translator resource calling the global endpoint requires both the resource key and Ocp-Apim-Subscription-Region; your request includes both with the documented regional value format.^2^

The combination of:

• both keys failing only at the global endpoint;
• the same key succeeding through the resource endpoint;
• Portal Try it failing;
• no corresponding calls appearing in resource metrics; and
• no client, key, resource, or network change at the onset

places the observed rejection before the request reaches the resource’s Translator processing path. It does not, by itself, reveal whether the cause is stale gateway entitlement, routing, or another service-side mapping problem.

A similar 401001/Portal Try it failure has required backend provisioning or entitlement validation through Microsoft Support, but that case does not establish the exact cause here.^3^

There is also no public incident evidence establishing an Azure-wide Translator global-endpoint outage for the specified time.^4^

One conditional configuration case

If Resource → Networking → Firewalls and virtual networks currently shows Selected Networks and Private Endpoints, global-endpoint rejection is expected: after VNet capability is enabled, Translator requires the custom endpoint and does not support the global endpoint.^1^

If networking remains public, that documented limitation does not explain this case; do not change networking merely to troubleshoot it.

Escalate with correlation data

From the Translator resource, select Support + Troubleshooting, complete the diagnostics, and then select Create a support request.^5^

Include:

1. Exact UTC onset and last-success timestamps.
2. One recent failed global request’s Date, X-RequestId, and apim-request-id.
3. One successful resource-endpoint request from the same minute.
4. The complete global and resource-specific URLs, with secrets removed.
5. The HTTP status and 401001 response body.
6. Screenshots or exports showing zero resource calls during the attempted traffic.
7. Portal Try it failure details.
8. Activity Log, Resource Health, and Service Health observations.
9. Confirmation that both keys reproduce the global-only failure.
10. A request to validate the resource’s global Translator gateway entitlement/routing association and confirm whether remediation or reprovisioning is required.

Only Microsoft Support can inspect that gateway-side association and provide a case-specific restoration commitment. Avoid deleting or recreating the working resource unless Support explicitly requests it, because doing so would change keys and endpoints without evidence that recreation will repair the global mapping.

References

1. Translator V3.0 Reference - Foundry Tools | Microsoft Learn
2. Authentication and authorization
3. Azure AI Translator not working after resource creation – Portal “Try it” fails and API returns 401001 across subscriptions - Microsoft Q&A
4. Azure status
5. Create an Azure support request