Read an ID Card Only

The short flow when you only need the data off an NID and not an identity check — pre-filling a form, reconciling an existing record, or digitising paperwork.

When to Use This

What	Description
Good fit	Auto-filling forms, digitising paper files, reconciling against data you already hold.
Not a fit	Opening an account, or anything that depends on the person holding the card being its owner.

WARNING

This flow does not verify identity. It reads the text off a card. Anyone holding someone else's card passes it. When you need real verification, use Onboard a New Customer.

The Flow

1. Upload images         (front, plus back if needed)
2. Check card quality    → stop if verdict ≠ good
3. Read the card         → check per-field confidence
4. Normalize and store

Step 1 — Upload

POST /v1/images

Use id_card.vn.national_id.front for the front. The back (...back) carries issue date, issuing authority and the MRZ.

→ Upload Image

Step 2 — Check quality

POST /v1/verify_id_card_sanity_sync

This step is cheap and prevents garbage OCR. Do not skip it even for data-only extraction — glare over the ID number produces a wrong number that still carries a high confidence_score.

→ Verify ID Card Sanity

Step 3 — Read the card

POST /v1/read_id_card_info_sync

The result merges three sources: OCR of the printed surface, the MRZ, and the QR. When the same field appears in more than one, prefer them in this order:

1. QR   — encoded at issuance, no recognition involved
2. MRZ  — machine-readable and checksum-protected
3. OCR  — image recognition, the most error-prone

→ Read ID Card Info

If you already have the QR string

When the app has scanned the QR, call this directly — it is faster and more accurate than OCR:

POST /v1/parse_qr_info_sync
{ "raw_qr": "001xxxxxxxxx|xxxxxxxxx|Nguyễn Văn A|12121990|Nam|Tổ 1, Phường Bến Nghé, Quận 1, TP. Hồ Chí Minh|01012021" }

It also decomposes the address into four administrative levels with their codes.

→ Parse QR Info

Step 4 — Normalize and store

Normalize before storing:

What	Description
Dates	Convert everything to YYYY-MM-DD.
Names	Title Case.
Addresses	Title Case, split across the four administrative levels.
Unicode	NFC normalization, strip duplicate spaces.

The eID documents the same field set with a recommended table schema; ask CAKE Support for it if you are storing the full NID record rather than a few fields.

Next Steps

• Parse QR Info — read straight from the QR string
• Onboard a New Customer — when you need real identity verification
• Verdict Definitions — what each image quality verdict means