Calling a verification API is the easy part. The engineering that decides whether it works in production is everything around it: what you send, where the threshold sits, what happens to a suspicious result, and what you can show an auditor a year later.
This guide covers how to architect that pipeline on top of a document verification API.
Architecture Overview
A production pipeline has five layers. Only one of them is the vendor's:
Document Input your app
↓
Pre-processing and routing your app
↓
Forensic + AI adjudication TamperCheck
↓
Decisioning against your thresholds your app
↓
Audit record + human review queue your app
The verification call is deliberately a single step. Everything that makes the system yours — which documents you send, what a risk_score of 60 means for your business, who reviews a flagged file — sits on either side of it.
What runs inside the verification step
Forensic analysis and AI adjudication both run on TamperCheck-managed infrastructure. There is no provider account to connect and no model to select: inference runs on audited models and is included in the per-document price. That is a deliberate trade — you lose model-level control, and in exchange there is no second vendor relationship, no key rotation, and nothing extra for a security review to cover.
Documents are analysed in memory and discarded when the verdict is returned. Nothing is written to disk, so there is no retention window to describe in a DPA and no deletion endpoint to call.
Pre-processing and Routing
Send fewer documents, not more
The cheapest verification is the one you skip. Most teams can cut volume substantially before the API is involved:
- Deduplicate. Applicants resubmit the same file across a flow. Hash the bytes and reuse the previous verdict.
- Route by risk. A returning customer topping up a small limit may not need the same scrutiny as a first-time applicant at maximum exposure.
- Filter the obviously broken. Zero-byte uploads, wrong MIME types, and password-protected PDFs should fail fast with a user-facing message rather than consuming a check.
Give the API what it needs
Pass document_type when you know it. Classification is automatic, but telling the API you are sending a bank statement rather than letting it infer that removes a failure mode:
curl -X POST https://api.tampercheck.ai/v1/verify \
-H "Authorization: Bearer tc_live_key_..." \
-F "file=@bank_statement.pdf" \
-F "document_type=bank_statement"Decisioning
Do not treat the verdict as the decision
The response gives you a verdict, a score, and the findings behind them:
{
"verdict": "TAMPERED",
"risk_score": 78,
"checks_run": 132,
"checks_failed": 3,
"findings": [
{
"check": "arithmetic_integrity",
"pass": false,
"detail": "Running balance off by $4,320 on page 2"
}
]
}The mistake is wiring verdict straight into an approve/decline branch. A verdict is evidence; the decision is yours and depends on what the document is for. A tampered utility bill on a low-value application is a different business event from a tampered bank statement on your largest loan of the quarter.
Three lanes, not two
Binary auto-approve/auto-decline throws away the most useful signal, which is uncertainty:
def route(result: dict, exposure: float) -> str:
score = result["risk_score"]
if score >= 70:
return "decline"
if score >= 30 or exposure > HIGH_VALUE_THRESHOLD:
return "manual_review"
return "approve"Start with a wide manual-review band and narrow it as you accumulate outcomes. Teams that begin with aggressive auto-decline generate false-positive complaints before they have the data to defend the threshold.
Act on findings, not just the score
Because each failed check names the field, you can route by what is wrong rather than only how wrong it is. An arithmetic failure on a bank statement is close to unambiguous; a single font-metric anomaly on a phone photo of a utility bill often is not. Different findings deserve different lanes.
Compliance and Audit Logging
What to log
Every verification should produce an immutable record. The point is to reconstruct, months later, why a human or a rule reached a decision:
{
"job_id": "job_abc123",
"timestamp": "2026-04-09T10:23:11Z",
"document_type": "bank_statement",
"verdict": "TAMPERED",
"risk_score": 78,
"checks_run": 132,
"findings": [...],
"threshold_version": "v4",
"routed_to": "manual_review",
"reviewer_id": null,
"final_decision": null
}threshold_version matters more than teams expect. When you tune a threshold, past decisions become unreproducible unless you recorded which rules were live at the time. Version your thresholds and store the version alongside the verdict.
Log the findings, not the document. Storing the submitted file to "support the audit trail" recreates exactly the retention surface the zero-storage design removes — and it is the part your compliance review will focus on.
Monitoring
Four metrics tell you whether the pipeline is healthy:
- Verdict distribution over time. A sudden shift in the clear/suspicious/tampered ratio means either a fraud wave or something upstream changing. Both are worth a page.
- Manual review queue depth and age. A review lane that grows faster than it drains is an auto-approve threshold set too tight.
- Override rate. How often reviewers disagree with the routing. Persistently high means your thresholds are wrong, not that your reviewers are.
- p95 end-to-end latency, split between your pre-processing and the verification call, so you know which half to fix.
Override rate is the one most teams skip and the one that pays for itself. It is the only metric that tells you whether the system is aligned with how your business actually makes decisions.
Build against the real API
Add $5 and we'll match it. Run your own documents through the pipeline before you write a line of integration code.
Test a fake document →FAQ
- Can I choose or configure the AI model?
No. AI inference is managed on audited models and included in the per-document price, so there is no provider account to connect and no keys to rotate. If model-level control is a hard requirement for your compliance posture, that is worth raising before you integrate.
- What actually runs during the verification step?
130+ forensic checks — automated document tampering detection across pixel analysis, arithmetic, font metrics, metadata, issuer templates, and AI-generated content — followed by an adjudication pass that assembles them into a verdict with named findings.
- Should I store the documents I verify?
That is your call, but store them because your business needs them, not for the audit trail. The findings and the verdict reconstruct the decision; the file itself adds retention risk without adding evidential value.
- Where can I learn what the forensic layer actually checks?
This guide covers pipeline design. For the forensic signal detail — what ELA, font metrics, arithmetic, and metadata analysis actually find — see the Complete Guide to Document Tampering and Fraud and the AI Agent Document Fraud Detection explainer.
- What document types can I verify through this pipeline?
All 100+ supported document types: passports, bank statements, payslips, invoices, credentials, utility bills, and more. See individual guides for each: bank statements, payslips, passports and IDs, insurance claims. For the full API request/response structure, see the Document Verification API Developer Guide.