How long does PDF analysis take?

Most PDFs get a verdict in two to five seconds. Complex documents of 50–100 pages can take five to fifteen seconds. These are typical figures, not guarantees: the time depends on how big and how complicated the file is, how quickly the file reaches HTPBE?, and how many other checks are running at that moment.

What happens between upload and verdict

Every check follows the same path, whether it starts in the web app or through the API:

• The file reaches HTPBE?. In the web app your browser sends the PDF straight to cloud storage. Through the API you send a public link and HTPBE? downloads the file itself.
• The analysis runs. The file is examined across metadata, file structure, digital signatures and embedded content.
• The result is stored and returned. You get a verdict – Intact, Modified or Inconclusive – and a permanent result page with the findings behind it.

In the web app you see an upload state and then an analysis state until the result page opens. The result appears on screen; there is no email to wait for.

What affects the time

• File size. Files up to 10 MB are accepted (see the file size limit). A larger file takes longer to arrive, and on the API it also takes longer to download from your server.
• Page count and complexity. A one-page invoice is the fast end of the range; a long document with many pages and objects is the slow end.
• Where the file is hosted (API only). HTPBE? downloads the PDF from your link, so a slow or throttled host adds to the total. A fast CDN or storage link keeps the download short.
• Load on the service. HTPBE? limits how many analyses run at the same time. When all slots are busy a new request is not queued silently: the API answers 429 with a Retry-After header telling you how many seconds to wait.

The API enforces two separate time limits: 30 seconds to download the file and 20 seconds for the analysis itself. A file that exceeds the analysis limit is rejected with a 422 error (analysis_timeout) instead of hanging. Nothing is stored and no credit is used. Unlike a malformed file, this one can succeed on a retry: wait a minute and try once or twice with backoff. If the same file keeps failing while the service is otherwise idle, it is too heavy to analyse within the limit.

Integrating the API: what to plan for

The HTPBE? API is synchronous. POST /v1/analyze returns 201 with the check id once the analysis has finished, and a follow-up GET /v1/result/{id} returns the full result immediately. You do not poll for completion.

• Set a generous client timeout. The download and analysis limits add up to 50 seconds in the worst case, so a client timeout of about 60 seconds avoids cutting off a request that is still legitimately running. Normal requests finish in a few seconds.
• Keep checks out of the user’s critical path where you can. For an upload form, show a short wait; for anything heavier, run checks in a background job and store the check id.
• Send an Idempotency-Key on every request you might retry. If your connection drops or times out, retrying with the same key returns the same check instead of spending a second credit.
• Retry only what can succeed. Retry 429, 500 and 409, honouring Retry-After and backing off exponentially otherwise. Do not retry 400 or 422 responses (except analysis_timeout), since the same input fails the same way.
• Batches: limit parallelism, do not fan out. Capacity is shared across the whole service, not per API key. Work through a batch with a small, bounded number of requests in flight, slow down on 429, and let the queue drain. If you need sustained high throughput, Enterprise plans can be set up with higher concurrency.
• Do not benchmark with test keys. Test keys return instant synthetic results without downloading or analysing a real file, so their timings say nothing about production. Measure latency with a live key on your own documents.

The full request, response and error contract is in the API documentation, and what the API response looks like shows the verdict fields.

Slow, failed or unfinished: telling them apart

• 201 with a check id. The analysis finished. The result is final, whether it is Intact, Modified or Inconclusive.
• 429 with Retry-After. All analysis slots were busy. Nothing ran. Wait the stated seconds and resend the same request with the same Idempotency-Key.
• 422 analysis_timeout. The analysis ran out of time. Nothing is stored or charged. A retry can succeed.
• 422 invalid_pdf. The file is malformed, encrypted or could not be processed. The same input fails the same way, so do not retry it; get a clean copy from the source.
• 201 with Inconclusive and status_reason: analysis_incomplete. The check could not be completed in full. This is a delivered result, not an error, and it counts as a check. Reading it again costs nothing. Treat the document as not fully checked rather than clean.

Planning a batch: a worked example

The figures below are an illustration, not a promise. Say a lender receives 200 statements overnight and a check takes about 3 seconds end to end. Sent one after another, that is around 10 minutes. With a small, bounded number of requests in flight, for example 5, the same batch finishes in a couple of minutes, and the service never has to refuse you. Pushing hundreds of simultaneous requests does not help: capacity is shared, the extra requests come back as 429 and you spend the time you saved on retries. Slow down when 429 appears, honour Retry-After, and store each check id as it arrives so a crash halfway through loses nothing.

When this does not apply

• Test keys return instant synthetic results, so their timing is not a guide.
• Reading a stored result with GET /v1/result/{id} is a lookup, not a new analysis, and returns at once.
• The time to open a result page in a browser is a page load, not an analysis.

If a check feels slow

• Check the file size first. Compressing a heavy scan or splitting a very long document can bring it under the limit and shorten the wait.
• On the API, test the download on its own: open the link in a browser or fetch it with curl from another network. A slow link is the usual cause of long waits.
• If you receive 429, wait for the Retry-After period and send the same request again.
• If a valid PDF consistently fails with the analysis-time error, contact support with the file link.

Pricing is per check, not per second: one check costs one credit however long it takes – see pricing. Teams that screen documents at volume can read how this fits into a pipeline on document fraud detection API, and anyone checking a single file can start with PDF tamper detection.

Related questions

• What is the file size limit for a PDF check?
• What does the API response look like?
• What is a credit, and how many does one check cost?