Skip to main content
The SDK exposes a single validate(request) call. The request type you construct selects the document and how it’s captured. There are two documents — Emirates ID and Passport — and for Emirates ID, three capture modes, each of which can optionally attach a fingerprint for biometric matching.
Each method must be enabled on your API key (Methods). Calling a method your key isn’t scoped for fails with METHOD_NOT_ALLOWED (1011) — see error codes.
The examples below use the desktop/Swift class-based shape; the type names are the same across Kotlin, C#, and C (see Naming across platforms), and each SDK guide shows the exact syntax for that language.

Emirates ID

Manual entry

Type the Emirates ID details — no hardware required. Good for quick, lower-assurance checks.

Card read

Reads the chip from a physical card on a smart card reader — proves the genuine card is present.
Prerequisites: a smart card reader, plus the mbkyc-pcsc-service desktop service on desktop. Get readerId from listSmartcardReaders().

Card read + fingerprint

Reads the chip and captures a live fingerprint, matching it against the card — the highest assurance (proves the cardholder is present).
Prerequisites: a smart card reader and a fingerprint sensor, plus their desktop services (mbkyc-pcsc-service + your fingerprint vendor’s service). See Biometrics for the finger-recommendation flow.
You can also attach a fingerprint to Manual entry (EmiratesIdManual(..., fingerprint:)) to add a biometric match without a card read.

NFC (Android only)

On Android, the Emirates ID chip can be read over the device’s built-in NFC instead of a USB reader — no smart card hardware needed. See the Android guide. Not available on desktop.

Passport

Manual entry

Type the passport details — no hardware required. No biometric variant.

Choosing a method

The result

Every method resolves to a VerificationResult: The data payload holds the resident’s verified details — Verification response documents every field it can contain.

Client reference ID

clientReferenceId ties a verification back to your own records — it’s echoed on the result and shown on the transaction.
It must be a UUID. If you omit it, the Validation Gateway generates one. If you supply a value that isn’t a valid UUID, it is silently ignored and replaced — so you’d lose your correlation with no error. Generate a UUID per verification (e.g. 3fa85f64-5717-4562-b3fc-2c963f66afa6).

Naming across platforms

The request type is named idiomatically per language but maps to the same method: