Real-Time Document Validation API: What It Checks and How Fast It Must Be
A real-time document validation API returns a verdict while the user is still on the screen. Here are the eight checks, a latency budget for each, and how to keep the total under a few seconds.
Table of contents
A real-time document validation API checks an uploaded document and returns a verdict while the user is still waiting on the screen. For most products that means under 5 seconds, for payments under 2, and for in-line fraud checks under 1. The verdict covers whether the file is valid, what type of document it is, what it says, whether the fields agree with each other, and whether it looks tampered with.
This guide lists the eight checks, gives each a latency budget, and explains the design choices that keep the total inside the window. The budgets are targets to plan against. They are not measurements of any one product, so test a real vendor on your own documents before you trust a number.
How fast does a document validation API need to be?
It depends on what the user is doing while they wait. The table shows the windows we plan against and what happens past each one.
| Total time | What the user feels | Typical use |
|---|---|---|
| Under 1 second | Instant | In-line fraud check, a step inside a wizard |
| 1 to 3 seconds | Fast | Customer onboarding, payment verification |
| 3 to 10 seconds | Acceptable with a progress indicator | Mortgage qualification, multi-document KYC |
| Over 10 seconds | People start to think it is broken | Treat it as a background job, not real-time |
For reference, DocsAPI's published speed is about 1.1 seconds per page, including the network round trip. That figure is for reading a page. Every extra check you run on top of it, such as fraud or sanctions screening, adds its own time, which is why the budget below matters.
What are the eight checks in a validation pipeline?
Real-time validation is a pipeline of small checks, not one check. Each step below has a target budget. Add them up before you promise a total to your users.
1. File integrity
Is this a valid image or PDF? Check the file signature, the size limit and run a malware scan. Target: under 50 milliseconds.
2. Pre-processing
Straighten skewed scans, fix rotation and find the page edges. See the document detection guide for why this comes before reading. Target: under 200 milliseconds.
3. Classification
What is this: a driver's license, a bank statement, a W-2? The answer decides which fields to look for next. See document classification. Target: under 150 milliseconds.
4. OCR and field extraction
Read the text and pull the fields that belong to that document type. This is usually the slowest step. Target: 300 to 800 milliseconds, depending on how complex the document is.
5. Field-level validation
Are the fields filled in, and in the expected format? Do the built-in checksums pass, such as the machine-readable zone on a passport? Target: under 100 milliseconds.
6. Cross-field consistency
Do the fields agree with each other? Is the issue date before today, and does the date of birth fit the expiry date? Target: under 50 milliseconds.
7. Fraud detection
Look for tampering, template mismatches and image artifacts. The document fraud detection guide covers what these checks look for. Target: 200 to 400 milliseconds.
8. External reference checks
Sanctions lists, politically exposed person lists and fraud databases. These depend on outside services, so they vary the most. Target: 200 to 500 milliseconds. See real-time sanctions screening for the difference between transaction speed and list freshness.
If you ran all eight one after another at the top of each range, the total would be about 2.25 seconds. Running some of them in parallel brings the wait down to roughly the length of the slowest chain.
Worked example: the budget for an onboarding upload
Here is the arithmetic for one upload, using the top of each budget above. These are the targets from this guide, not measured numbers.
| Step | Starts at | Ends at |
|---|---|---|
| File integrity | 0 ms | 50 ms |
| Pre-processing | 50 ms | 250 ms |
| Classification | 250 ms | 400 ms |
| OCR and extraction | 400 ms | 1,200 ms |
| Fraud detection (runs alongside, once the image is ready) | 250 ms | 650 ms |
| Field validation, then cross-field checks | 1,200 ms | 1,350 ms |
| External reference checks (alongside field checks) | 1,200 ms | 1,700 ms |
The verdict is ready at about 1.7 seconds, because the external checks are the last to finish. That is inside the 2-second payment window, with only 300 milliseconds to spare. If the external checks slow down, they are the ones to move to a webhook.
How do you keep the total under a few seconds?
Run independent checks in parallel
Steps 1 to 4 depend on each other, so they run in order. After extraction, field validation, cross-field checks and external lookups can run at the same time, and fraud detection can start as soon as the image is ready. The wait is set by the slowest chain, not by the sum of all of them.
Stop early when a step fails
If the file is not a valid PDF, do not spend time reading it. If classification fails, skip the field checks that depend on it. Each step gates the next, and a failure returns right away with a clear reason.
Give every step a deadline
If reading takes too long, stop it and ask the user to re-upload a clearer copy. Most users prefer a fast retry to a slow success.
Move slow checks to a webhook
Some checks, such as a full sanctions screening with a list refresh, cannot finish in two seconds. Return the fast results at once, mark the slow check as pending, and deliver its result by webhook when it completes.
Return the same answer for the same file
If a user uploads the same document twice because of a retry or an error, return the stored result instead of running the pipeline again.
What makes a real-time validation pipeline slow?
- Everything runs in sequence. Checks that could run together wait in a line, and the total grows by the sum of the steps.
- No per-step timing. Without median and 95th-percentile times for each step, you cannot see which one is the problem. A pipeline that feels slow usually has one step that occasionally takes many seconds.
- All-or-nothing failure. If one check fails and the whole request fails with it, the user gets nothing. Return what you have, mark what failed, and route the rest to human review.
What should a pipeline return?
A useful response has three parts: a verdict (pass, review or reject), the extracted fields with a confidence for each, and a list of which checks ran and which are still pending. A pending webhook check should show up as pending, not as passed.
Should you build or buy a real-time validation pipeline?
For most teams, buy. Getting eight checks under a few seconds needs ongoing work on extraction speed, fraud models and external data feeds. If you want to compare buying against building, the build vs buy guide shows the same trade-off for invoices.
When you evaluate vendors, ask for median and 95th-percentile latency on a document like yours, and ask which checks run before the answer comes back and which arrive later by webhook. A vendor who cannot answer in seconds is probably not built for real-time. For the accuracy side of the same question, see the OCR accuracy benchmark, and for identity documents see KYC document verification.
Frequently asked questions
A real-time document validation API takes an uploaded document and returns a verdict while the user waits. The verdict covers file validity, document type, extracted fields, consistency between fields, fraud signals and external list checks. Most products aim for under 5 seconds, and payment flows aim for under 2.
It depends on the workflow. In-line fraud checks need under 1 second, payment verification under 2, and onboarding can tolerate 5 to 10 seconds with a progress indicator. Past 10 seconds, treat it as a background job.
Not fully. The API can pass documents that clear every check, but low-confidence, ambiguous or flagged documents still need a person. Route those to review instead of forcing a pass or a reject.
We plan for 200 to 400 milliseconds for fraud checks, and we run them in parallel with extraction so they do not add to the wait. This is a planning target, not a measured result for any one product.
For most teams, buy. Keeping eight checks inside a few seconds takes ongoing work on extraction speed, fraud models and external data. Ask vendors for median and 95th-percentile latency on a document like yours.
The pipeline is the same. Payroll validation uses different field templates, for pay stubs, tax withholding forms and direct deposit instructions, but the same checks and latency budget apply.
Related Blog Posts
How to Measure OCR Accuracy: CER, WER and Field Scores (2026)
Plain definitions of character error rate, word error rate and field level accuracy, a Python script with real output, what score counts as good, and how to test on your own documents.
Context Engineering for Document AI (Beyond RAG, 2026)
My first RAG demo for invoice Q&A failed in front of the CFO. The fix was not better embeddings, it was better context engineering. Here is what I learned.
Document Detection: The Step Everyone Skips Before OCR
Our OCR accuracy jumped four percentage points the day we stopped feeding rotated junk into the engine. Document detection is the cheapest, most-skipped accuracy win in the field.
Want to see it on your own documents?
Try our free OCR tool in your browser, or book a demo to see how DocsAPI reads the document types covered in this guide.