Mistral Document AI 2512, suddenly facing 422 errors for passing in the same payload as before. Seeing 422s for passing in table_format, extract_header, extract_footer.

Question

Mistral Document AI 2512, suddenly facing 422 errors for passing in table_format, extract_header, extract_footer. This was working completely fine until very recently. And with no changes to the request payload, we're seeing 422 errors.

After changing the payload to not pass table_format, extract_header, extract_footer. we're not seeing the 422 error.
However we need these values to be passed in for my use case.
The description of the model still mentions that these features are configurable. And i don't see any schema changes on the mistral api docs
https://ai.azure.com/catalog/models/mistral-document-ai-2512

Answer 1

Hi Sujith,

Good news: this isn't something you broke on your end. What you're describing matches a known gateway/schema-sync gap on the mistral-document-ai-2512 deployment in Microsoft Foundry, and a few other people hit it the same week you did.

What's actually happening Mistral shipped an OCR update (OCR 3 / mistral-ocr-2512) that introduced table_format as a supported parameter, along with extract_header and extract_footer. Microsoft Foundry doesn't call Mistral's global API directly — it fronts the model with its own request-validation gateway that enforces a fixed request schema. When Mistral's native endpoint was updated to accept these new fields but Microsoft hadn't yet updated the schema on the Foundry gateway to match, the gateway treats them as unrecognized properties and rejects the whole request with a 422 rather than just ignoring the extra fields. That lines up exactly with what you're seeing: identical payload, only the presence of those three keys triggers the failure. Mistral AIMicrosoft Learn

You're also not the only one — another user hit the identical failure mode on the same OCR endpoint passing document_annotation_prompt, getting a 422 with an "extra_forbidden" error type pointing at that field, even though it's documented in Mistral's own API and SDK. That's a strong signal this is a broader schema-lag issue on this specific model version, not something specific to your table/header/footer fields.

Quick way to confirm it's this and not something else Pull the full 422 response body (not just the status code). If this is the same issue, you should see something like:

"detail":[{"type":"extra_forbidden","loc":["body","table_format"],"msg":"Extra inputs are not permitted"}]

One entry per rejected field. If you see extra_forbidden there, that confirms it's the gateway schema, not your payload structure or auth.

What to do in the meantime

1. If losing header/footer separation temporarily is workable: drop extract_header/extract_footer from the request. By default, header/footer text is just folded into the normal page markdown instead of being split into separate header/footer fields not ideal, but it keeps things running while you wait on a fix.
2. For table_format specifically: omitting it entirely falls back to the default (null), which still returns tables inline as markdown — so if markdown-in-page is acceptable short term, you don't lose table content, just the separate tables array / HTML option.
3. If you need these fields now and can't wait: calling Mistral's own global OCR endpoint directly (outside Foundry) for just this call path will work today, since their schema already accepts these parameters — worth doing only if that fits your data-residency/compliance requirements.
4. If you need a stable Foundry deployment right now: some users have temporarily pinned back to mistral-document-ai-2505 for this call path until 2512's gateway schema catches up you lose the newer table/header/footer controls, but you avoid the 422 entirely.

Thanks,
Manish.

Answer 2

Hi! Since the unchanged payload succeeds only after removing those three properties, the endpoint’s active validation schema no longer matches the catalog description. Confirm the deployment version and API version, then capture the complete 422 response body and request ID. Keep the reduced payload as a temporary workaround. This should be reported to Foundry Support as a possible model-provider schema regression, especially if a newly created deployment behaves identically.