Process a loan application packet
Split a mixed packet into typed, extracted records.
Goal. Take the pile of documents a borrower submits — financial statements, tax returns, bank statements, incorporation papers, IDs — and turn it into one structured application record, without asking a human to sort it first.
This is the composition recipe. It reuses Classify, then extract and Extract many documents at once at packet scale, and the interesting parts are the routing and the assembly rather than any single call.
Before you start
An API key, exported as
$DOCAI_API_KEY.A packet — individual files, or a ZIP.
A publicly reachable HTTPS endpoint if you want push completion, per Build an event-driven pipeline. Recommended: a packet is a lot of ~90-second extractions.
The shape of the problem
A packet arrives with no reliable labelling. Filenames are scan_004.pdf. One PDF may hold three documents. Some types matter to your credit decision and some are supporting material.
So the pipeline is: identify everything → decide what to extract → extract in parallel → assemble → review what is weak or missing.
Step 1 — Classify everything
python -c "
import base64, glob, json
files = [{'content': base64.b64encode(open(p,'rb').read()).decode()}
for p in sorted(glob.glob('packet/*.pdf'))]
json.dump({'files': files}, open('classify-bulk.json','w'))
"
curl -X POST "https://api-docai-uat.uptiq.ai/classify/bulk" \
-H "X-Api-Key: $DOCAI_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @classify-bulk.jsonFor a ZIP, each member is classified separately and the results carry classificationGroupId, classificationGroupIndex and classificationGroupTotal.
Step 2 — Route on type and confidence
Map classified types onto what your process does with them:
Default unrecognised types to review, never to discard. The registry is larger than any routing table you write by hand, and it grows without a release — see Discovering document types. A document silently dropped because nobody added its type is the failure mode that actually hurts.
Step 3 — Extract what matters
Submit the routed documents as a batch, each with the type classification found:
Setting metadata per file matters here. Group results come back keyed by document type, not by submission order, so metadata is how you get back to "which file was this".
Pass industry on financial documents to load a default chart of accounts — see Spread a set of financials.
Step 4 — Assemble the record
Collect children as they complete, whether by webhook or by GET /document-extractions/group/{id}:
Step 5 — Check completeness against your policy
The packet being processed is not the same as the packet being complete. Check what you require, not just what arrived:
This is where the value shows up. A packet missing its P&L is identified in seconds rather than at the end of a credit review.
Step 6 — Screen for document integrity
For anything that carries weight in the decision, check the fraud signals on the extraction record before you rely on the numbers:
Remember that fraud analysis finishes after extraction does — see Reading fraud and control checks before wiring this into a gate.
What a good outcome looks like
No flags, all required types present
Straight through to the credit process
Low-confidence extractions
Route those documents to review, keep the rest
Missing required documents
Go back to the borrower immediately, with specifics
Failed integrity checks
Hold for the risk team
Unrecognised types
Human triage — and consider extending the routing table
Related pages
Classify, then extract — the two-step this recipe scales up.
Extract many documents at once — batch submission and group retrieval.
Spread a set of financials — what happens next with the financial documents.
Reading fraud and control checks — the integrity gate.
Document Types — the registry your routing table draws on.
Last updated
Was this helpful?

