Data extraction
An OCR ID scanning API that returns structured fields, not a block of text.
ShieldID turns a government photo ID into structured, per-field data: name, date of birth, document number, expiry, address and more, each one carrying its source and its own verdict. A document data extraction API and a document verification API in the same session.
What comes back
Structured fields, where the document actually carries them.
Not every document carries every field. ShieldID returns what the document has, and marks what it does not.
- Full name
- As printed, and as encoded in the barcode or the MRZ where the document carries one.
- Date of birth
- Read from the printed face and cross-checked against the barcode and the MRZ.
- Document number
- License number or passport number, checked for internal consistency where the issuer's format allows it.
- Expiry date
- Read from the printed face and the barcode or MRZ.
- Address
- Read from the printed face and the barcode where present; comparable against a separately uploaded address document.
- Sex
- Read where the document prints or encodes it.
- Issuing jurisdiction
- Identified from the barcode issuer code where the document carries a recognized one, as available.
Three sources, one comparison
Barcode, MRZ and the printed front, read on purpose, not blended by accident.
Every field is attributed to the source it came from. When two sources disagree, that is a flag on the result, not an average of the two numbers.
PDF417 barcode
The back of a North American driver's license or ID card is decoded into structured AAMVA fields. When a document carries a barcode, its fields take priority over the printed front.
Passport MRZ
The machine-readable zone is located, read, and validated against the ICAO check-digit formulas built into the zone. A minimum validity score, checked against that score, gates whether an MRZ-read field is trusted at all — a zone that fails its own checksum does not get to override a cleaner source.
Structured and full-page OCR of the front
The printed face is read using the document's own layout where one is recognized, falling back to full-page OCR so an unfamiliar document still yields readable fields.
Conflicts are flagged, not averaged
A name or date of birth that disagrees between the front, the barcode and the MRZ is reported as a mismatch on the result. Nothing in the pipeline silently picks a winner and hides the disagreement.
MRZ checksum validation
A machine-readable zone has to check its own math before we trust it.
The ICAO machine-readable zone on a passport carries check digits by design. ShieldID validates them before treating an MRZ-read field as reliable.
A dedicated detector locates the MRZ, a reader extracts the characters, and the result is scored for validity against the zone's own checksum formulas. Only a field that clears the minimum validity score is trusted at full priority; a zone that reads poorly is treated accordingly rather than passed through as if it were clean.
Barcode-first priority
When sources overlap, the most reliable one wins.
The same field can appear on the barcode, in the MRZ and on the printed front. ShieldID resolves that with one consistent order, every time.
- PDF417 barcode
- Passport MRZ, once it passes its checksum
- Structured reading of the printed front
- Full-page OCR fallback
Address documents
Upload a second document, get a straightforward address comparison.
When a verification requires proof of address, the applicant uploads a separate document and ShieldID reads it the same way it reads the ID.
The address document is put through OCR, and its address is compared against the address read from the ID document. This is a plain text and token comparison, not a separate document classifier, and it is only run when the session calls for it and a document was actually supplied.
Redaction and PII handling
Extracted data is protected the same way the images are.
Structured fields sit alongside the same privacy controls that apply to the ID photos themselves.
Date of birth encrypted at rest
Date of birth is stored encrypted at rest; the service will not run without the encryption key in place.
Images purged on a timer
The captured document and selfie images are purged automatically on a short timer, seven days by default. A sweep runs on an interval and again shortly after every restart, so a quiet period never lets an image sit past the day it should be gone.
On-device score redaction
Where a match or confidence figure would otherwise be shown to the applicant's own phone, ShieldID strips the underlying percentage from that message before it is displayed, so a raw score is never surfaced outside your account.
The record outlives the images
The images go on a schedule. The fact that a verification happened, and what it found, stays in your account — and, for a Trust Ledger integration, as a verified/failed entry in the Activity Ledger (ledger entries for ShieldID API accounts: Coming soon).
Sample result
Per-field verdicts, in the shape the API returns.
Names, numbers and addresses below are invented for this example. The field set, the sourcing and the verdicts are the real shape of a result.
| Field | Value | Source | Verdict |
|---|---|---|---|
| person.name | "Maria Gonzalez" | barcode | match |
| person.dob | "1991-07-22" | barcode | match |
| person.document_number | "D1234567" | barcode | match |
| person.document_country | "US" | barcode issuer code | match |
| person.address | "1428 Elm St, Sacramento, CA" | barcode | match |
| identity.name_match | PASS | front vs barcode vs requester | PASS |
| checks.document_tamper | "no_indication" | advisory model | advisory, not gating |
// Sample result. Names, numbers and addresses are fictional.
{
"session_id": "ses_9f2c...sample",
"status": "VERIFIED",
"environment": "sandbox",
"person": {
"name": "Maria Gonzalez",
"dob": "1991-07-22",
"document_type": "DRIVERS_LICENCE",
"document_country": "US",
"document_jurisdiction": "CA",
"address": "1428 Elm St, Sacramento, CA"
},
"identity": {
"checks": ["name_match"],
"warnings": [],
"sources": {
"name": "barcode",
"dob": "barcode",
"address": "barcode"
}
},
"checks": {
"document": "PASS",
"identity": "PASS",
"document_tamper": "no_indication"
},
"completed_at": "2026-09-17T14:02:11Z"
}Integration notes
The same fields, wherever you read the result.
Structured fields are not a separate product from the verification session. They arrive as part of the same result.
- Fields are delivered in the session result you fetch through the API once a verification completes.
- The same result is delivered to your endpoint by a signed webhook when the verification finishes, so you do not have to poll for it.
- Every field is attributed to its source and carries its own verdict, both in the API result and in the webhook payload.
- Sandbox sessions return the same field shape as production, so you can build your integration before a single real document is read.
Questions
Straight answers about data extraction.
See the fields for yourself
Run a sandbox verification and read the structured result.
Create a sandbox session, scan a document on your own phone, and see every field, its source and its verdict in the response. Sandbox sessions are never billed.