Mistral OCR rejects valid PDFs: `document_parser_invalid_file` (error 3740)

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

Not specified by the original author.

TL;DR

Do not waste time re-encoding the PDF - check the Mistral status or issue tracker first, because this class of failure has been fixed server-side before.

Steps

1. Error 3740 Document is not a valid PDF on a file you know is valid is an API-side parser bug, not your file. Do not waste time re-encoding the PDF - check the Mistral status or issue tracker first, because this class of failure has been fixed server-side before. If you are blocked, retry after the fix window or shrink the file: the confirmed failing cases were large or generator-produced PDFs (report-generator output, 100+ page documents), and splitting them into smaller chunks is a reasonable workaround while the parser is being fixed.
2. Also searched as: "3740 Document is not a valid PDF on valid files - an API-side parser bug"

When to use

You are seeing this: Error 3740 Document is not a valid PDF on a file you know is valid is an API-side parser bug, not your file. Use this skill when you run into "Error 3740 Document is not a valid PDF on valid files - an API-side parser bug".

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.

Edge cases

• Also searched as: "3740 Document is not a valid PDF on valid files - an API-side parser bug"

Source: Issue mistralai/client-python#485 (closed, 8 comments): Mistral OCR rejected valid PDFs with error 3740 - Document is not a valid PDF, documentparserinvalid_file - including invoices from the combit List and Label report generator and a 128-page 12 MB journal PDF. Reporters confirmed the files opened fine elsewhere. A Mistral maintainer deployed a server-side fix and reporters confirmed it worked.

Verified resolution: Error 3740 Document is not a valid PDF on a file you know is valid is an API-side parser bug, not your file. Do not waste time re-encoding the PDF - check the Mistral status or issue tracker first, because this class of failure has been fixed server-side before. If you are blocked, retry after the fix window or shrink the file: the confirmed failing cases were large or generator-produced PDFs (report-generator output, 100+ page documents), and splitting them into smaller chunks is a reasonable workaround while the parser is being fixed.

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

Not specified by the original author.

Mistral OCR: inline base64 fails with 'Failed to fetch document'

TL;DR

Do not inline base64 into the document field when calling Mistral OCR. Upload the file first with purpose=ocr, fetch a signed URL with an expiry, and send that URL as document_url. If you get 'Failed to fetch document', check that the URL is reachable by Mistral's servers, not just by you.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Context: GitHub issue (mistralai/platform-docs-public #269): sending an inline base64 data URI as imageurl to POST /v1/ocr returns 400 with 'Failed to fetch document'. The reporter followed the docs example and still hit it, so it is not just a formatting slip. Gotcha that trips agents: Mistral OCR wants a URL it can fetch. For local files, use the three-step flow instead: upload to POST /files with purpose=ocr, grab a signed URL from GET /files/[id]/url, and pass that as documenturl.

Source: GitHub issue (mistralai/platform-docs-public #269): sending an inline base64 data URI as imageurl to POST /v1/ocr returns 400 with 'Failed to fetch document'. The reporter followed the docs example and still hit it, so it is not just a formatting slip. Gotcha that trips agents: Mistral OCR wants a URL it can fetch. For local files, use the three-step flow instead: upload to POST /files with purpose=ocr, grab a signed URL from GET /files/[id]/url, and pass that as documenturl.

Verified resolution: Do not inline base64 into the document field when calling Mistral OCR. Upload the file first with purpose=ocr, fetch a signed URL with an expiry, and send that URL as document_url. If you get 'Failed to fetch document', check that the URL is reachable by Mistral's servers, not just by you.

Source URL: https://github.com/mistralai/platform-docs-public/issues/269