This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(70.4, 88%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENG%3C/text%3E%3C/svg%3E)
Calls to a mistral-document-ai-2512 serverless deployment on Microsoft Foundry intermittently return HTTP 408 "upstream request timeout" and HTTP 503 "service unavailable" when the payload uses document_url with a base64-encoded PDF. The exact same endpoint, deployment, model and credentials succeed reliably when the payload uses image_url with a base64-encoded image. PDF inputs were working consistently until a few days ago, without any change on our side.
https://<resource>.cognitiveservices.azure.com/providers/mistral/azure/ocr
mistral-document-ai-2512 (deployed as global-standard serverless)
{
"model": "mistral-document-ai-2512",
"document": {
"type": "document_url",
"document_url": "data:application/pdf;base64,<...>"
},
"include_image_base64": false
}
{
"model": "mistral-document-ai-2512",
"document": {
"type": "image_url",
"image_url": "data:image/png;base64,<...>"
},
"include_image_base64": false
}
Two distinct errors are returned, both server-side:
408 - upstream request timeout
503 - service unavailable
The errors appear non-deterministic — the same PDF payload can return 408 on one attempt and 503 on the next. Far below our 50 RPM quota in every case (no 429 ever observed).
pages: [0] to restrict processing to the first page only — same 408 / 503 mixinclude_image_base64 set to both true and false — same behaviorpages: [0] to minimize processing loadinclude_image_base64document_url (PDF) path of mistral-document-ai-2512 over the past few days?image_url pipeline? The clear asymmetry (PDFs fail, images succeed on the same endpoint) suggests separate backend handling.Thanks for any guidance from the Foundry or Mistral team.
Calls to a mistral-document-ai-2512 serverless deployment on Microsoft Foundry intermittently return HTTP 408 "upstream request timeout" and HTTP 503 "service unavailable" when the payload uses document_url with a base64-encoded PDF. The exact same endpoint, deployment, model and credentials succeed reliably when the payload uses image_url with a base64-encoded image. PDF inputs were working consistently until a few days ago, without any change on our side.
https://<resource>.cognitiveservices.azure.com/providers/mistral/azure/ocr
mistral-document-ai-2512 (deployed as global-standard serverless)
{
"model": "mistral-document-ai-2512",
"document": {
"type": "document_url",
"document_url": "data:application/pdf;base64,<...>"
},
"include_image_base64": false
}
{
"model": "mistral-document-ai-2512",
"document": {
"type": "image_url",
"image_url": "data:image/png;base64,<...>"
},
"include_image_base64": false
}
Two distinct errors are returned, both server-side:
408 - upstream request timeout
503 - service unavailable
The errors appear non-deterministic — the same PDF payload can return 408 on one attempt and 503 on the next. Far below our 50 RPM quota in every case (no 429 ever observed).
pages: [0] to restrict processing to the first page only — same 408 / 503 mixinclude_image_base64 set to both true and false — same behaviorpages: [0] to minimize processing loadinclude_image_base64document_url (PDF) path of mistral-document-ai-2512 over the past few days?image_url pipeline? The clear asymmetry (PDFs fail, images succeed on the same endpoint) suggests separate backend handling.Thanks for any guidance from the Foundry or Mistral team.
Calls to a mistral-document-ai-2512 serverless deployment on Microsoft Foundry intermittently return HTTP 408 "upstream request timeout" and HTTP 503 "service unavailable" when the payload uses document_url with a base64-encoded PDF. The exact same endpoint, deployment, model and credentials succeed reliably when the payload uses image_url with a base64-encoded image. PDF inputs were working consistently until a few days ago, without any change on our side.
https://<resource>.cognitiveservices.azure.com/providers/mistral/azure/ocr
mistral-document-ai-2512 (deployed as global-standard serverless)
{
"model": "mistral-document-ai-2512",
"document": {
"type": "document_url",
"document_url": "data:application/pdf;base64,<...>"
},
"include_image_base64": false
}
{
"model": "mistral-document-ai-2512",
"document": {
"type": "image_url",
"image_url": "data:image/png;base64,<...>"
},
"include_image_base64": false
}
Two distinct errors are returned, both server-side:
408 - upstream request timeout
503 - service unavailable
The errors appear non-deterministic — the same PDF payload can return 408 on one attempt and 503 on the next. Far below our 50 RPM quota in every case (no 429 ever observed).
pages: [0] to restrict processing to the first page only — same 408 / 503 mixinclude_image_base64 set to both true and false — same behaviorpages: [0] to minimize processing loadinclude_image_base64document_url (PDF) path of mistral-document-ai-2512 over the past few days?image_url pipeline? The clear asymmetry (PDFs fail, images succeed on the same endpoint) suggests separate backend handling.Thanks for any guidance from the Foundry or Mistral team.
Calls to a mistral-document-ai-2512 serverless deployment on Microsoft Foundry intermittently return HTTP 408 "upstream request timeout" and HTTP 503 "service unavailable" when the payload uses document_url with a base64-encoded PDF. The exact same endpoint, deployment, model and credentials succeed reliably when the payload uses image_url with a base64-encoded image. PDF inputs were working consistently until a few days ago, without any change on our side.
https://<resource>.cognitiveservices.azure.com/providers/mistral/azure/ocr
mistral-document-ai-2512 (deployed as global-standard serverless)
{
"model": "mistral-document-ai-2512",
"document": {
"type": "document_url",
"document_url": "data:application/pdf;base64,<...>"
},
"include_image_base64": false
}
{
"model": "mistral-document-ai-2512",
"document": {
"type": "image_url",
"image_url": "data:image/png;base64,<...>"
},
"include_image_base64": false
}
Two distinct errors are returned, both server-side:
408 - upstream request timeout
503 - service unavailable
The errors appear non-deterministic — the same PDF payload can return 408 on one attempt and 503 on the next. Far below our 50 RPM quota in every case (no 429 ever observed).
pages: [0] to restrict processing to the first page only — same 408 / 503 mixinclude_image_base64 set to both true and false — same behaviorpages: [0] to minimize processing loadinclude_image_base64document_url (PDF) path of mistral-document-ai-2512 over the past few days?image_url pipeline? The clear asymmetry (PDFs fail, images succeed on the same endpoint) suggests separate backend handling.Thanks for any guidance from the Foundry or Mistral team.
A catalog of AI models in Microsoft Foundry that you can discover, compare, and deploy using Azure’s built‑in tools for evaluation, fine‑tuning, and inference
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(224.00000000000003, 98%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EOS%3C/text%3E%3C/svg%3E)
I am also having this same problem, my foundry is deployed in West US 3.
Where is yours?
Central-Sweden but it has been fixed this morning, I think it was just a server overload.
The context only documents mistral-document-ai-2512 as an image-to-text model that accepts image or PDF pages as input and describes general behavior for capacity and throttling, but it doesn’t contain any product note or incident information about regressions, nor internal routing details for document_url vs image_url. It also doesn’t document 408/503 patterns specific to this model.
From the available information, only the following can be stated:
mistral-document-ai-2512 capabilitiesmistral-document-ai-2512 is listed as an Image-to-Text model with:
enThis confirms that PDF input is officially supported for this model, but the context doesn’t describe any current regression or known issue with the PDF (document_url) path.
The provisioned-throughput documentation explains how capacity issues are normally surfaced:
retry-after headers to guide client behavior.There is no mention in the context of 408 or 503 being the expected signal for capacity exhaustion on Foundry Models; instead, 429 is the documented behavior when capacity is constrained.
The batch and “on your data” troubleshooting content documents other error codes and conditions (e.g., too_many_tasks, model_not_found, invalid_request, search 503s due to Azure AI Search throttling), but none of these are specific to mistral-document-ai-2512 or to PDF ingestion via document_url.
The 503 guidance that does exist is for Azure AI Search queries in “on your data” scenarios, where 503 can be caused by insufficient replicas/partitions and mitigated by scaling or adding retry/sleep logic. That guidance is specific to search resources and doesn’t describe the Mistral OCR endpoint.
document_url for mistral-document-ai-2512The provided documentation and Q&A snippets contain no statement about any regression, outage, or capacity issue specific to mistral-document-ai-2512, nor to its document_url (PDF) path.
image_urlThe context only states that the model accepts “image or PDF pages” as input. It does not describe internal routing, separate pipelines, or architectural differences between PDF and image handling for mistral-document-ai-2512.
The capacity documentation for Foundry Models states that when capacity is exceeded, the API returns 429 and that this is by design as the capacity signal. There is no documentation here that 408 or 503 are used as the standard signal for capacity issues on Foundry Models, even when within RPM quota.
The context does not provide any model-specific workaround guidance for mistral-document-ai-2512 PDF issues. General guidance for capacity or backend issues includes:
However, there is no explicit recommendation in the context for handling intermittent 408/503 on this specific OCR endpoint, nor any alternative PDF ingestion pattern beyond what is already being used.
Given the constraints of the provided documentation, any further guidance (such as confirming a regression, explaining backend routing, or proposing product-level mitigations) would require escalation through Azure support or service health channels, which are not described in detail in this context.
References: