UnsupportedDocumentException on PDFs - use StartDocumentAnalysis not AnalyzeDocument

Not specified by the original author.

TL;DR

For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG.

Steps

1. UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. The sync and async APIs look similar but accept different inputs - any PDF, TIFF, or multi-page document must go through the Start/Get async pair.

When to use

You are seeing this: UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. Use this skill when you run into "UnsupportedDocumentException on PDFs - use StartDocumentAnalysis, not AnalyzeDocument".

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: Stack Overflow 60501332 (accepted answer, 13 votes): calling AnalyzeDocument on a PDF with boto3 threw UnsupportedDocumentException. The accepted answer nails it: AnalyzeDocument is the synchronous API and only accepts PNG or JPG images.

Verified resolution: UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. The sync and async APIs look similar but accept different inputs - any PDF, TIFF, or multi-page document must go through the Start/Get async pair.

Source URL: https://stackoverflow.com/questions/60501332

Not specified by the original author.

Mathpix: image OCR is sync, document conversion is async with polling

TL;DR

Route images to the v3/text image endpoint and PDFs to the async document flow, then poll status until the conversion completes before fetching output. If your Mathpix call fails on a PDF, check which endpoint you hit first. For batch pipelines, use the confidence thresholds to catch bad OCR instead of trusting every result.

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: Repo README (mathpix/mpxpy, the official Python client): documents that single-image OCR and document conversion are two different flows. Images go to v3/text synchronously, but PDF and document conversion is async: submit the file, then poll for completion before downloading outputs in MMD, Markdown, DOCX, LaTeX, or HTML. Gotcha that trips agents: POSTing a PDF to the image endpoint fails. The README also documents an isasync flag for non-interactive image requests and confidencethreshold knobs that raise errors on low-confidence OCR instead of silently returning junk.

Source: Repo README (mathpix/mpxpy, the official Python client): documents that single-image OCR and document conversion are two different flows. Images go to v3/text synchronously, but PDF and document conversion is async: submit the file, then poll for completion before downloading outputs in MMD, Markdown, DOCX, LaTeX, or HTML. Gotcha that trips agents: POSTing a PDF to the image endpoint fails. The README also documents an isasync flag for non-interactive image requests and confidencethreshold knobs that raise errors on low-confidence OCR instead of silently returning junk.

Verified resolution: Route images to the v3/text image endpoint and PDFs to the async document flow, then poll status until the conversion completes before fetching output. If your Mathpix call fails on a PDF, check which endpoint you hit first. For batch pipelines, use the confidence thresholds to catch bad OCR instead of trusting every result.

Source URL: https://github.com/mathpix/mpxpy/blob/HEAD/README.md

Not specified by the original author.

TL;DR

10s connect and 40s read - and pass it into the ExecutionContext alongside your credentials.

Steps

1. When the SDK throws the generic Request could not be completed error on specific PDFs, suspect the default timeouts before the documents. Build a ClientConfig with explicit timeouts - e.g. 10s connect and 40s read - and pass it into the ExecutionContext alongside your credentials. The reporter's files parsed fine once the read timeout was raised; the SDK just gave up too early and wrapped it in a meaningless exception.

When to use

You are seeing this: When the SDK throws the generic Request could not be completed error on specific PDFs, suspect the default timeouts before the documents. Use this skill when you run into "Generic SdkException on some PDFs is a timeout - set custom ClientConfig timeouts".

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: Stack Overflow 68372461 (accepted answer, 2 votes): Adobe PDF Services threw a generic SdkException - Request could not be completed - on some company report PDFs with no useful detail. The accepted answer found the files were fine in Node and diagnosed it as a timeout, not a document problem.

Verified resolution: When the SDK throws the generic Request could not be completed error on specific PDFs, suspect the default timeouts before the documents. Build a ClientConfig with explicit timeouts - e.g. 10s connect and 40s read - and pass it into the ExecutionContext alongside your credentials. The reporter's files parsed fine once the read timeout was raised; the SDK just gave up too early and wrapped it in a meaningless exception.

Source URL: https://stackoverflow.com/questions/68372461