Mistral never auto-expires OCR file uploads - delete

Not specified by the original author.

TL;DR

Delete the file ID right after you get the OCR result, and prefer passing image URLs or bytes directly when you can avoid the upload entirely.

Steps

1. Clean up your Files API uploads after Mistral OCR calls. Mistral does not auto-expire files you upload for OCR, so every processed PDF lingers in your file store unless you delete it - a slow storage leak and a data-retention problem for sensitive documents. Delete the file ID right after you get the OCR result, and prefer passing image URLs or bytes directly when you can avoid the upload entirely.

When to use

You are seeing this: Clean up your Files API uploads after Mistral OCR calls. Use this skill when you run into "Mistral never auto-expires OCR file uploads - delete them yourself".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: paperless-gpt Mistral OCR integration docs: when documents are uploaded through Mistral's Files API for OCR, Mistral does not expire those uploads automatically - the integration deletes each file right after the OCR call (best-effort) because nothing is uploaded in image mode.

Verified resolution: Clean up your Files API uploads after Mistral OCR calls. Mistral does not auto-expire files you upload for OCR, so every processed PDF lingers in your file store unless you delete it - a slow storage leak and a data-retention problem for sensitive documents. Delete the file ID right after you get the OCR result, and prefer passing image URLs or bytes directly when you can avoid the upload entirely.

Source URL: https://github.com/icereed/paperless-gpt/blob/HEAD/docs/mistral_llm.md

Not specified by the original author.

TL;DR

If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed.

Steps

1. If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed. The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection.

Expected: A Mistral maintainer confirmed the typing bug and shipped the fix in the 1.5.2 release.

When to use

You are seeing this: The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection. Use this skill when you run into "files.upload purpose ocr fails type checking - fixed in mistralai 1.5.2".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: mistralai 1.5.2. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Issue mistralai/client-python#196 (closed, 6 comments): calling files.upload with purpose set to ocr failed type checking - the purpose parameter's type did not accept ocr even though the API does. A Mistral maintainer confirmed the typing bug and shipped the fix in the 1.5.2 release.

Verified resolution: If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed. The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection.

Source URL: https://github.com/mistralai/client-python/issues/196

Not specified by the original author.

TL;DR: if Mistral OCR rejects a valid PDF with document_parser_invalid_file (error 3740) and the file opens fine in every PDF reader, it is not your file. Mistral shipped a bad change to their PDF processing on 2026-04-11 that rejected certain valid PDFs; they rolled it back the same evening and deployed a full fix on April 13. The fix is server-side and already live, so just retry. If it still fails, open a fresh issue, since the April incident is resolved.

The error, verbatim:

SDKError: API error occurred: Status 400 ... "message": "Document is not a valid PDF.",
"type": "document_parser_invalid_file", "code": "3740"

Steps

1. Sanity-check the file: open it in two different PDF readers. Expected: it opens fine everywhere, and other PDFs work through the API. If it does not open, the file is genuinely broken; this is not your case.
2. Retry the same OCR request unchanged. Expected: the same file now processes successfully, because the bad deploy was rolled back and fixed server-side around April 13, 12:00 UTC.
3. Success check: you get normal OCR output with no 3740 error.
4. If the error persists on a reader-valid file, open a fresh issue with Mistral; the April incident is closed, so a repeat is a new bug.

When to use this

• Error 3740 / document_parser_invalid_file on a PDF that opens in other readers.
• The same file worked before mid-April 2026 or works intermittently.

When NOT to use this

• The file does not open in standard readers; fix the file first.
• 401/403 errors; those are auth problems.

Compatibility

• Mistral OCR API (mistral-ocr-latest), incident window 2026-04-11 to 2026-04-13. Server-side only; no client upgrade needed.

Variant phrasings

• mistral ocr 3740 valid pdf rejected
• "Document is not a valid PDF" mistral-ocr-latest
• mistral documentparserinvalid_file combit pdf

Root cause

Mistral's April 11 deploy rejected PDFs whose image objects carry a null /Matte reference, an optional PDF 1.7 compositing hint most parsers ignore silently. Files from generators like combit List & Label carried that reference and got rejected. Mistral partially rolled back on April 11 at 21:00 UTC and deployed the full fix around 12:00 UTC on April 13.

Edge cases

• Files generated by other report tools could hit the same path during the incident window; the fix covered all of them, not just combit output.
• Sending as a base64 data URL vs a document URL made no difference; the rejection was in PDF parsing, not upload handling.

In the thread Mistral OCR rejects valid PDFs: document_parser_invalid_file (error 3740), the question was: I am sending a valid PDF to the Mistral OCR API (mistral-ocr-latest) as a base64 data URL, and it rejects it with: SDKError: API error occurred: Status 400 ... "message": "Document is not a valid PDF.", "type": "document_parser_invalid_file", "code": "3740". The same file opens fine in every PDF reader, and other PDFs work through the API. The file was generated by the combit List & Label report generator. Is this a known issue? The verified resolution: Yes, this was a Mistral-side bug, not your file. On 2026-04-11 Mistral shipped a bad change to their PDF processing that rejected certain valid PDFs — in your case, PDFs whose image objects carry a null /Matte reference (an optional PDF 1.7 compositing hint most parsers ignore silently). Mistral first rolled back part of the change on April 11 at 21:00 UTC, then deployed a full fix around 12:00 UTC on April 13, after which reporters confirmed the same files processed fine. So: if you are hitting error 3740 on a file that opens in other readers, retry — the fix is server-side and already deployed. If it still fails, open a fresh issue, since the April incident is resolved. Original discussion: https://vectle.com/threads/thrMCQEWCoe-9bzna2JMBBWw