What are the limits?

Three that will stop you, all enforced by the service.

Three pages per request

A PDF with four or more pages is rejected outright. It is not truncated and not partially processed:

{"success":false,"message":"only up to 3 pages are supported for extraction","errors":null}

Split the document and send the pages that carry the data. For an invoice that is usually the first page and the last; for a resume, the first three.

qpdf --empty --pages long.pdf 1-3 -- first3.pdf

This is the limit that bites hardest on scanned documents and academic CVs, which are exactly the things that tend to run long.

Five requests a second

The rate limit is per API key, with a burst of five, and it returns 429 when exceeded. Batch work needs a throttle on your side; a tight loop over a directory will trip it.

Falling back to your IP happens only when no key is sent at all, so every key gets its own budget.

There is a second, slower cap on how many client instances one key registers in 24 hours. If you see too many instances created last 24 hours with a 429, that is it.

Credits are per page

A three-page document costs three, not one. The unit is pages processed, so splitting a six-page invoice into two requests costs the same six as sending it whole would have, had that been allowed.

is_scanned=true does not change the price. It adds page images to the request, which costs latency, not credits.

When the balance runs out:

{"success":false,"message":"available credits exceeded for organization","errors":null}

Balance and usage are in the UniCloud dashboard.

Other things to plan for

There is no documented maximum file size, but you are bounded by three pages in practice.

Latency scales with pages and with whether images are sent. A one-page born-digital invoice comes back in about a second. A three-page scan with is_scanned=true takes noticeably longer, so set a client timeout well above what you measure rather than at it.

Nothing is queued or retried for you. Retry a 429 with backoff, and a 200 whose body will not decode, since that is a truncated stream.

Cap those retries. Credits are committed before the model runs, so a truncated 200 has already been charged and each retry charges the pages again. An unbounded loop on a document that keeps truncating will spend real credit; two or three attempts and then a failure you can look at is the right shape.

Do not blanket-retry 500s. failed to read PDF file is a 500 even though the upload is the problem, so retrying sends the same unreadable file again. That one costs nothing, because the PDF is rejected before any charge, but it will never succeed either. Retry a 500 only if the same request succeeded before.