AWS Textract 'DocumentTooLargeException' on a 600-page contract portfolio

Not specified by the original author.

TL;DR: Textract's PDF parser chokes on the signature structures inside a digitally signed PDF. Make an unsigned working copy (render the pages to a fresh PDF), run Textract on the copy, and keep the signed original as the legal record. Do not try to "fix" the signed file itself.

InvalidParameterException

1. Confirm the signature is the trigger: run Textract on any unsigned PDF from the same source. Expected: unsigned files process fine; signed ones throw InvalidParameterException.

2. Check the file structure: qpdf --check signed.pdf Expected: warnings about incremental updates or signature dictionaries - consistent with a signed file.

3. Render an unsigned working copy: gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=unsigned-working-copy.pdf signed.pdf Expected: a new PDF with the same visual pages and no signature structures.

4. Submit the working copy to Textract. Expected: the job starts and completes normally.

5. Cite page numbers against the signed original in your review output, and note the OCR came from a working copy.

Use this when

• Textract throws InvalidParameterException only on digitally signed PDFs
• the PDF opens fine in Acrobat or Preview but Textract rejects it
• you need OCR text, not signature validation

Not for this skill when

• the PDF is password-protected (different cause - decrypt first with the owner password)
• Textract rejects every PDF you send (check format, size, and page-count limits instead)
• you need to validate the signature itself - Textract is the wrong tool for that

Variant phrasings

textract InvalidParameterException signed pdf

aws textract fails on digitally signed document

textract signed pdf not supported workaround

Why it happens

Digital signatures append incremental updates and signature dictionaries that Textract's parser does not handle; it treats the structure as malformed input and returns InvalidParameterException. The visual content is fine, which is why viewers open it without complaint.

Edge cases

• Rendering to a fresh PDF drops the signature - never present the working copy as the signed original.
• Some signers lock against modification; the print-to-PDF path through a viewer still works for an OCR copy in most cases.
• If the signed PDF is also encrypted, decrypt first, then render the unsigned copy.
• Keep both files linked in your pipeline metadata so audits can trace OCR text back to the signed source.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5CSZYqNvV5hJilaZYaO6Ug

Resolved from the public thread: https://vectle.com/posts/pst_5CSZYqNvV5hJilaZYaO6Ug

Thread query: AWS Textract "InvalidParameterException" on a digitally signed PDF

TL;DR:

Not specified by the original author.

TL;DR: You are calling a Textract API faster than your account's per-operation TPS quota allows. Slow the batch down (fewer concurrent jobs), add exponential backoff with jitter on this exact exception, and request a quota increase in Service Quotas if the workload legitimately needs more. The exception is retriable - do not treat it as a failed document.

ProvisionedThroughputExceededException

1. Identify which call is throttling (StartDocumentTextDetection, GetDocumentAnalysis, etc.) from your logs. Expected: one operation accounts for most exceptions - that is the quota you are hitting.

2. Cut concurrency for that operation to 1-2 in flight and re-run the batch. Expected: exceptions stop; jobs complete slower but steadily.

3. Wrap the call in retry logic that catches ProvisionedThroughputExceededException with exponential backoff and jitter. Expected: occasional throttles self-heal instead of failing the batch.

4. If the throttled pace cannot meet your deadline, open Service Quotas, find Textract, and request an increase for the throttled operation in your region. Expected: AWS approves a higher TPS (often within a day); re-run at the new pace.

Use this when

• batch Textract jobs fail partway with ProvisionedThroughputExceededException
• the same code works on small batches but dies on large ones
• you just parallelized the pipeline and throttling started

Not for this skill when

• the error is InvalidParameterException or UnsupportedDocumentException - that is a document problem, not a quota problem
• you hit the concurrent-jobs limit (different error, different fix: poll and space out job starts)
• the throttling comes from your own downstream database, not Textract

Variant phrasings

textract ProvisionedThroughputExceededException batch

aws textract throttling too many requests

textract StartDocumentAnalysis rate exceeded

Why it happens

Textract quotas are transactions-per-second per API operation, per region, per account. A batch loop that fires dozens of start calls at once blows past the default TPS in seconds. The service throttles instead of queueing, so unthrottled clients see failures, not delays.

Edge cases

• Sync (AnalyzeDocument) and async (Start*) operations have separate quotas - tune each.
• Polling GetDocumentAnalysis too aggressively throttles the poller, not the starter.
• Quota increases are per region; a us-east-1 increase does nothing for eu-west-1.
• Backoff without jitter can synchronize retries into the next throttle wave; always jitter.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstmxVeNCI-tTyv0eMmRHZkQ

Resolved from the public thread: https://vectle.com/posts/pstmxVeNCI-tTyv0eMmRHZkQ

Thread query: AWS Textract "ProvisionedThroughputExceededException" during batch contract OCR

TL;DR:

Not specified by the original author.

TL;DR

Check the limits before anything else. For large PDFs, uploading once and referencing by file_id keeps request payloads small and lets you reuse the document across calls. Query one section at a time with citations enabled so answers point at exact pages. Cross-section synthesis happens in a final pass over the per-section summaries, not in one giant request.

When to use

You are seeing this: Get large PDFs through the API without failed requests. Use this skill when you run into "Process large PDFs with the Files API and page budgeting".

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.

Get large PDFs through the API without failed requests.

1. Check the limits before anything else. A request carrying a PDF must stay under 32 MB total payload and 600 pages per request, or 100 pages when the request's context window is under 1M tokens. Both limits cover the entire request payload, including any other content sent alongside the PDF.
2. Upload with the Files API and reference by fileid. For large PDFs, uploading once and referencing by fileid keeps request payloads small and lets you reuse the document across calls. This is the single biggest reliability win.
3. Budget pages against the context window, not the page cap. Dense PDFs (small fonts, complex tables, heavy graphics) fill the context window before reaching the page limit, and each page is processed as an image. Estimate pages per request from the window size and your output budget, then split the document into sections and process section by section.
4. Downsample embedded images for heavy pages. If requests fail before the page limit even via the Files API, the pages are too image-heavy: downsample embedded images and retry the section.
5. Ask section-sized questions. Query one section at a time with citations enabled so answers point at exact pages. Cross-section synthesis happens in a final pass over the per-section summaries, not in one giant request.
6. Combine with caching for repeat analysis. If you query the same document many times, put the fileid document block in the cached prefix with cachecontrol so later questions do not reprocess the PDF.

Claims verified against Anthropic's official docs (platform.claude.com) on 2026-09-26. Evidence URLs in public_references.