Microsoft Foundry api change

Question

Hey,

we are using the mistral-document-ai-2512 model with the microsoft foundry. We where sending some extra api params which are documented by mistral on their page. https://docs.mistral.ai/studio-api/document-processing/basic_ocr

table_format, extract_header, extract_footer - these params where working perfectly fine for 2 months now, until last week.
There seems to have been a change made by microsoft which increased the strictness of their api.
We are presented with the following errors now:

"{"error":{"code":"Invalid input","message":"{\"detail\":[{\"type\":\"extra_forbidden\",\"loc\":[\"body\",\"extract_header\"],\"msg\":\"Extra inputs are not permitted\",\"input\":true},{\"type\":\"extra_forbidden\",\"loc\":[\"body\",\"extract_footer\"],\"msg\":\"Extra inputs are not permitted\",\"input\":true}]}","status":422}}

Is it possible that microsoft adds support offically for these params or reverts back to allowing extra params?

Thanks in advance.

Answer 1

Hi J,

What you're seeing is expected behavior, and unfortunately it's unlikely to be reverted. Here's what happened and what your options are.

Why it broke

The extra_forbidden / "Extra inputs are not permitted" error is a Pydantic strict-schema rejection on Microsoft's side. Azure AI Foundry wraps the Mistral model behind its own API schema, which is not identical to Mistral's native docs.mistral.ai API. Foundry only validates against the fields it explicitly defines.

Previously, Foundry's schema silently ignored unknown fields (lax mode). Last week's change tightened validation to reject any field not in their schema — so table_format, extract_header, and extract_footer, which are documented by Mistral but not part of Foundry's published contract, now fail with HTTP 422.

Key point: those params being documented on Mistral's site doesn't mean they're supported on Azure — the Mistral-native API and the Azure Foundry-hosted endpoint are two different surfaces. The tightening is almost certainly intentional (security/consistency hardening), so waiting for a "revert to allow extra params" isn't a reliable plan.

What you can do now

Call Mistral's native API directly for OCR. If you specifically need table_format / extract_header / extract_footer, the only surface that officially supports them today is Mistral's own Document AI API (api.mistral.ai). That guarantees the params are honored rather than silently dropped or rejected.

Check whether Foundry exposes an equivalent. Azure's Document Intelligence / Foundry OCR may offer header/footer and table extraction through its own parameter names or output structure (e.g. layout/table features in the response) rather than these Mistral-specific flags. Review the Foundry model's API reference for the mistral-document-ai-2512 deployment to see what fields it actually accepts.

Remove the unsupported fields to unblock immediately. If you send the request without extract_header / extract_footer / table_format, it will succeed — you just won't get that extra extraction behavior via Foundry.

File the official feature request. To ask Microsoft to formally add these params to the Foundry schema, the effective channels are:

Azure Support ticket from the Azure portal (Help + Support → New support request) referencing the mistral-document-ai-2512 deployment.

Azure AI Foundry feedback at https://feedback.azure.com — a public request there is what product teams actually track for schema additions.

A forum post here won't reach the Foundry product team directly, so a support ticket + feedback item is the way to get an authoritative answer on whether they'll add official support.

Recommendation

If these extraction params are business-critical right now, route those specific OCR calls to Mistral's native Document AI API, and keep using Foundry for everything covered by its schema. In parallel, open an Azure support ticket to get an official statement and request the params be added to the Foundry contract.

Hope this helps clarify what changed.