KTP OCR
Read every field on an e-KTP.
Structured identity fields from a KTP photo, with NIK consistency checks.
POST /v1/ktp/ocr scope: document:ocr
Key points
Why teams use KTP OCR
All KTP fields
NIK, name, place and date of birth, gender, address, religion, marital status, occupation and more.
Built-in consistency checks
The NIK is checked against the printed birth date and gender.
Explicit access
Responses contain personal data, so keys need the separate document:ocr scope.
How it works
From request to result
- Send a photo of the KTP front in a signed POST.
- Text is read and mapped to KTP fields, then normalized.
- Receive fields with confidence and consistency checks.
Know the limits. Reading a card does not prove it is genuine. For document checks and a decision, use KYC Verify.
Billed per processed card. Images with no readable KTP text (422) and errors are free.
Full API reference →request · examplePOST
POST /v1/ktp/ocr
Idempotency-Key: 1d9e…
{ "document": { "image": "<base64 KTP>" } }response · example200
// example — never use real identity data
{
"data": {
"status": "EXTRACTED",
"fields": {
"nik": { "value": "3201••••0001", "confidence": 0.XX },
"nama": { "value": "B••• S•••••", "confidence": 0.XX }
},
"checks": { "nik_matches_birth_date": "PASS" }
}
}FAQ
Questions
Are OCR values stored?
Values go only to the caller. Stored records keep the status, which fields were read and a masked NIK.
Put KTP OCR into production.
Request access and our team activates your account, or talk to sales about volume.
KTP OCR · from Rp150Request API access