Affinda uploads block by default: use wait=false plus polling or webhooks for large docs

Not specified by the original author.

TL;DR

For batch jobs or big files, set wait=false and poll GET /v3/documents/{id} until ready is true, or better, subscribe to webhooks and fetch the document when document.parse.completed arrives.

Steps

1. Affinda's default upload is synchronous (wait=true): the call blocks until parsing finishes, and it will time out on large or complex documents. For batch jobs or big files, set wait=false and poll GET /v3/documents/{id} until ready is true, or better, subscribe to webhooks and fetch the document when document.parse.completed arrives. Two more knobs that matter at scale: lowPriority: true routes to the low-priority queue with no submission limit (the high-priority queue is 30 docs/min and 429s past that), and passing documentType skips the classification step entirely when you already know what the document is.

When to use

You are seeing this: Affinda's default upload is synchronous (wait=true): the call blocks until parsing finishes, and it will time out on large or complex documents. Use this skill when you run into "Affinda uploads block by default: use wait=false plus polling or webhooks for large docs".

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: Official docs via community-verified skill reference (docs.affinda.com): create_document blocks until parsing completes by default (wait=true), which can timeout on large or complex documents. The production pattern is wait=false: you get a document identifier back immediately, then either poll GET /documents/{id} until ready is true or receive a webhook when processing completes. Upload params also include lowPriority (routes to the no-rate-limit queue) and documentType (skips classification when you know the type).

Verified resolution: Affinda's default upload is synchronous (wait=true): the call blocks until parsing finishes, and it will time out on large or complex documents. For batch jobs or big files, set wait=false and poll GET /v3/documents/{id} until ready is true, or better, subscribe to webhooks and fetch the document when document.parse.completed arrives. Two more knobs that matter at scale: lowPriority: true routes to the low-priority queue with no submission limit (the high-priority queue is 30 docs/min and 429s past that), and passing documentType skips the classification step entirely when you already know what the document is.

Source URL: https://docs.affinda.com/reference/documents

Not specified by the original author.

Docsumo webhooks: status callbacks beat polling the document status endpoint

TL;DR

Configure a webhook instead of polling for document status; you get notified on uploaded, processed, and reviewed transitions. Route the payload's document identifiers straight into your downstream job. Keep a status poll as a fallback in case a webhook delivery fails.

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: Official docs (Docsumo webhooks): documents account-configured webhook callbacks that POST a JSON payload to your endpoint when a document changes processing status (uploaded, processed, reviewed), carrying document identifiers and status for downstream automation.

Source: Official docs (Docsumo webhooks): documents account-configured webhook callbacks that POST a JSON payload to your endpoint when a document changes processing status (uploaded, processed, reviewed), carrying document identifiers and status for downstream automation.

Verified resolution: Configure a webhook instead of polling for document status; you get notified on uploaded, processed, and reviewed transitions. Route the payload's document identifiers straight into your downstream job. Keep a status poll as a fallback in case a webhook delivery fails.

Source URL: https://support.docsumo.com/docs/webhook-1

Not specified by the original author.

TL;DR

Large PDFs time out because the upload is one long request past the API's time limit, often made worse by slow networks or a proxy with its own ceiling. Check whether the file API supports chunked, multipart, or resumable upload and use it. If only single-shot upload exists, compress the PDF or split it into smaller parts, upload each, and record the assembly. Always verify the uploaded file: size match and a readable first and last page, because a timed-out upload can leave a partial file the API considers complete.

agent could not upload supporting docs: the file API timed out on PDFs over 10MB

Use this when

• PDF uploads over about 10MB time out while smaller PDFs upload fine.
• The failure is a timeout, not an auth error or a file-type rejection.
• The agent needs the full document attached to a rec or close record.

Not for this skill when

• All uploads fail regardless of size. That is connectivity, auth, or endpoint configuration, not a size limit.
• The API rejects the PDF as an unsupported type. Convert or re-export the document first.

Steps

1. Confirm the size boundary: upload test files of increasing size and find where timeouts begin. Verify: the threshold is measured, not assumed at 10MB
2. Check the file API's docs for chunked, multipart, or resumable upload support. Verify: the available upload patterns are listed from documentation
3. If chunked upload exists, implement it with per-chunk retries and a finalisation call. Verify: a 50MB test PDF uploads reliably through the chunked path
4. If only single-shot upload exists, compress the PDF or split it into parts under the threshold, and upload each part with clear naming. Verify: each part uploads and the parts are recorded as a set
5. Verify integrity of every uploaded document: byte size match and spot-check pages, then link the upload to its rec or close record. Verify: the record's attachment opens complete

Variant phrasings

file API timeout PDF over 10MB upload chunked

The large-upload phrasing.

agent upload supporting docs large PDF split compress

When splitting or compressing.

Compatibility: File upload APIs for supporting documents in reconciliation and close platforms.

Why it happens

Upload timeouts are time limits, not size limits: a 10MB file on a fast network uploads fine while the same file on a slow one times out, which is why the threshold feels inconsistent. Single-shot uploads couple the whole file to one request's lifetime, the same structural flaw as synchronous exports. Chunked upload decouples them, and where it is unavailable, smaller files are the honest substitute. Integrity verification matters because partial uploads are the silent version of this failure.

Edge cases / pitfalls

• Compress with OCR-safe settings; aggressive compression can blur scanned pages and break downstream text extraction.
• Some APIs accept a URL or a staged file reference instead of bytes; staging to object storage then referencing it avoids the upload ceiling entirely.
• Keep the original unsplit PDF in the working papers; the split parts are a transport artefact, not the record copy.

Provenance

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

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

Thread query: agent could not upload supporting docs: the file API timed out on PDFs over 10MB

TL;DR: Large PDFs time out because the upload is one long request past the API's time limit, often made worse by slow networks or a proxy with its own ceiling. Check whether the file API supports chunked, multipart, or resumable upload and use it. If only single-shot upload exists, compress the PDF or split it into smaller parts, upload each, and record the assembly. Always verify the uploaded file: size match and a readable first and last page, because a timed-out upload can leave a partial file the API considers complete.