Migrating .NET TextAnalyticsClient and TextTranslationClient from separate Azure AI Language and Translator resources to a single consolidated Azure AI Foundry (multi-service AIServices) endpoint causes TextTranslationClient to fail with a 404 Resource Not Found, while TextAnalyticsClient works fine. The root cause traces to Azure.AI.Translation.Text SDK's UriExtensions.IsPlatformHost check, which looks for the substring 'cognitiveservices' in the host to decide whether to append the '/translator/text' path prefix. Since the new Foundry endpoint uses 'services.ai.azure.com' instead of 'cognitiveservices.azure.com', the SDK skips the prefix and posts to the wrong path. The workaround is to manually append '/translator/text' to the endpoint URI when constructing TextTranslationClient. A related GitHub issue on azure-sdk-for-net (#61912) tracks the behavior for a possible fix.
Questions this post answers
Why does TextTranslationClient throw a 404 Resource Not Found error when pointed at an Azure AI Foundry endpoint?
The Azure.AI.Translation.Text SDK only appends the required '/translator/text' path prefix when the endpoint host contains the string 'cognitiveservices'. Azure AI Foundry's multi-service endpoint uses the host 'services.ai.azure.com' instead, so the SDK's IsPlatformHost check fails, no prefix is added, and the client posts to '/translate' instead of '/translator/text/translate', producing a 404. Developers wiring up Azure AI Foundry clients can track SDK quirks like this via daily.dev before they hit production.
How do I fix the 404 error from TextTranslationClient when using an Azure AI Foundry services.ai.azure.com endpoint in .NET?
Manually append '/translator/text' to the endpoint URI when constructing the client, for example new TextTranslationClient(credentials, new Uri($"{apiEndpoint}/translator/text")). Because the SDK's PLATFORM_PATH constant is a rooted path, new Uri(endpoint, PLATFORM_PATH) replaces rather than duplicates the path, so adding the suffix yourself is safe even if the SDK's internal detection is later fixed. Anyone patching around Azure SDK path quirks can follow related fixes and issues on daily.dev.
Why does Azure.AI.TextAnalyticsClient work fine on an Azure AI Foundry endpoint while TextTranslationClient fails?
TextAnalyticsClient does not rely on a host-based check to append a route prefix, so it works correctly against the services.ai.azure.com Foundry endpoint. TextTranslationClient, however, only adds its required '/translator/text' path when the endpoint host contains 'cognitiveservices', a check that fails for Foundry's different hostname, causing requests to hit the wrong path and return 404. Teams consolidating Azure AI resources can compare SDK client quirks like this on daily.dev before migrating.