Mistral Document AI (with OCR 4) deployment succeeds, but generated REST endpoint returns HTTP 404

Hello Aleksandr Kodiakov,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Mistral Document AI (with OCR 4) deployment succeeds, but generated REST endpoint returns HTTP 404.

This is caused by using the wrong invocation path, most commonly testing Mistral Document AI OCR 4 as if it were a chat/completions model, using an incorrect endpoint route, using the model catalog name instead of the deployment name, or sending an unsupported document source format. Microsoft Foundry deployments must be called using the deployment endpoint and deployment name, while Mistral Document AI OCR requires an OCR/document payload rather than a normal chat prompt. - https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/endpoints, https://github.com/microsoft-foundry/foundry-samples/blob/main/samples-mistral/python/mistral-docai-basics.ipynb, https://docs.mistral.ai/studio-api/document-processing/basic_ocr

Therefore, the resolution is to:

• Copy the exact Target URI/Endpoint, API key, and Deployment name from the Mistral Document AI deployment page in Microsoft Foundry.
• Do not validate this model through a chat playground or Azure OpenAI chat-completions request. OCR 4 is a document OCR capability and requires an OCR/document-processing request.
• Do not guess or append routes such as /v1/chat/completions or /v1/ocr unless that exact OCR target URI is shown in the deployment code sample. Use the endpoint exactly as provided by Foundry.
• Send the document as a valid base64 data URL first, because Microsoft’s Mistral Document AI Foundry sample uses base64-encoded documents for the reliable Azure Foundry OCR call pattern.
• Put the deployment name in the model field, not the public model card name unless both are intentionally identical in your deployment.

If the direct OCR REST call still fails after using the exact Foundry endpoint, valid key, correct deployment name, and valid base64 PDF, capture the HTTP status code, response body, request ID, timestamp, region, deployment name, and model version, then open an Azure support case. At that point, the likely cause is deployment-specific service behavior, endpoint provisioning, regional availability, policy, quota, or a platform-side issue rather than user code. Foundry deployment availability, deployment types, and model routing are governed by the Foundry deployment model and resource configuration. https://learn.microsoft.com/en-us/azure/foundry/concepts/deployments-overview, https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/create-model-deployments

Use the above and below resource links for more reading and steps:

• Microsoft Foundry model endpoints - https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/endpoints
• Microsoft Foundry Mistral Document AI sample: - https://github.com/microsoft-foundry/foundry-samples/blob/main/samples-mistral/python/mistral-docai-basics.ipynb
• Mistral Document AI with OCR 4 announcement in Microsoft Foundry: - https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/mistral-document-ai-with-ocr-4-and-mistral-medium-3-5-arrive-in-microsoft-foundr/4529863
• Mistral OCR processor documentation: - https://docs.mistral.ai/studio-api/document-processing/basic_ocr

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Aleksandr Kodiakov hi & thx for sharing urs issue here at Q&A portal,

a Succeeded deployment only proves the model was created. It doesn’t always prove the generated sample endpoint is the right runtime route. https://<resource>.services.ai.azure.com/models looks too generic. For Foundry model inference, u normally need the exact model/deployment invocation path and api-version from the View code panel for that deployment. If the generated sample gives /models and every call returns plain 404, I’d suspect a bad generated sample or the REST route for Mistral Document AI/OCR 4 isn’t enabled yet on that endpoint.

Since other Mistral models work from the same resource, auth/resource/network are prob fine. This looks scoped to the OCR 4 deployment/runtime route. Check whether the model has a different task-specific API path for document/OCR calls rather than normal chat/completions. OCR/document models often don’t use the same /chat/completions style route as text models.

https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/create-model-deployments

https://learn.microsoft.com/en-us/azure/ai-foundry/model-inference/how-to/use-chat-completions

https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/models-sold-directly-by-azure

Best move rn is open a Foundry support case w/ resource name, region, deployment name, model name/version, generated curl sample, UTC timestamp, and response headers/body from the 404. Ask MS to confirm the correct REST path/api-version for Mistral Document AI OCR 4.

So my take its not ur key. Not ur curl. Most likely the generated endpoint is wrong or the service route for this newly announced model isn’t wired up cleanly yet.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/