Mistral Document AI (OCR 4) deployment on AIServices+Project returns 404 on all invocation paths (/v1/ocr, /v1/files)

Question

Environment

• Resource type: Microsoft.CognitiveServices/accounts (kind: AIServices), with an associated Foundry project
• Two separate deployments tested, same result on both:
  • foundry-ara-dev (Italy North) — deployment created 2026-07-27
  • a second, older AIServices resource (Sweden Central) — deployment created 2026-07-15
• Model deployed: mistral-ocr-4-0 (format: "Mistral AI", provisioningState: Succeeded, deploymentState: Running)
• SDK: Python mistralai package, and raw HTTP via httpx/requests

Problem

Every attempt to invoke the deployed OCR model returns:

{"error":{"code":"404","message": "Resource not found"}}

This happens both via the mistralai SDK (client.files.upload(), client.ocr.process()) and via raw REST POST requests, tested against every combination of:

• Domain: https://<resource>.cognitiveservices.azure.com and https://<resource>.services.ai.azure.com
• Path: /v1/ocr, /v1/files, /ocr, /models/<deployment>/ocr
• Auth header: Authorization: Bearer <key> and api-key: <key>
• API version: with and without ?api-version=2024-05-01-preview

Both resources confirm: API key is valid (no 401), resource is online, deployment shows "Running" — the 404 is specific to the invocation path/routing, not auth or provisioning.

What I'm looking for

What is the correct Target URI / invocation pattern for a mistral-ocr-4-0 deployment created on an AIServices resource + Foundry project (not a legacy AML-based serverless/MaaS endpoint)? Specifically:

• Should the Files API (upload + get_signed_url) even be used for this deployment type, or does OCR expect inline base64 document_url only?
• Is there a project-scoped endpoint (e.g. via azure-ai-projects SDK) required instead of the raw resource endpoint?

Related reports (none resolved for this exact deployment type)

• Mistral Document AI (with OCR 4) deployment succeeds, but generated REST endpoint returns HTTP 404 — unresolved, no confirmed working path.
• Attempting to Consume Mistral OCR Serverless Endpoint — resolved, but only for a legacy <deployment>.<region>.models.ai.azure.com serverless endpoint, which doesn't exist for AIServices+Project deployments (confirmed via az resource list — no Microsoft.MachineLearningServices/workspaces/serverlessEndpoints resource present).
• Mistral OCR deployed on Azure AI Foundry not working — unresolved, reports ~3% success rate on a similar deployment.

Any pointer to the correct Target URI format, or confirmation this is a known platform issue, would be appreciated.

Answer 1

You’ve isolated this to the OCR 4 data plane: both deployments are Running, authentication is accepted, and every tested OCR or Files route returns 404. For AIServices-based Foundry resources, Microsoft documents the common resource-level Models endpoint; however, the current Model Inference API publishes no OCR or Files operation for mistral-ocr-4-0. The project Files API is for Foundry Agent files, not Mistral OCR input, so a project-scoped endpoint is not appropriate.

In the deployment’s Consume/View code panel, copy the exact Target URI, deployment name, headers, and payload. Test that sample unchanged with one inline base64 image or PDF, not client.files.upload(). If the portal-generated URI still returns 404 in both regions, there is no documented client-side route to fix. Open Microsoft Support with both deployment IDs, regions, timestamps, and request or correlation IDs, and ask the Foundry team to validate OCR 4 data-plane routing for AIServices deployments.