Skip to main content
One complete verification: from your backend’s request to the decision on your webhook. chmod verifies that the person using your app is who they say they are. The user photographs their identity document and takes a short liveness selfie; chmod checks that the document is genuine, that a real person is present, that the two faces match, that the device is trustworthy, and that what the document says agrees with what you already know. You get a decision, and every reason behind it. It is built for products that onboard real people and cannot afford to get it wrong: fintech and payments, lending, marketplaces, gig platforms, telcos, anything regulated.

​
How it works

The integration is two halves, owned by two teams, joined by one token.
1

Your backend opens a verification

It registers the person as a customer, then creates a transaction carrying the rules to enforce — which documents to accept, how strict the face match should be, what to do about a rooted phone. The response includes an sdk_token.
2

Your app runs the capture

It hands the token to the chmod SDK. The SDK renders document capture, the liveness check and a result screen, then returns completed, cancelled or failed.
3

chmod analyses

Document extraction and authenticity, liveness, face comparison, device integrity, data matching, and consistency with the customer’s history — all of it, to completion, usually within seconds.
4

Your backend receives the decision

APPROVED, REJECTED or UNDETERMINED, delivered by webhook and readable at any time by id, with a stable code for every finding.
The SDK returning completed means the user finished the flow, not that they were approved. The verdict arrives afterwards, on your backend. Show “we’re reviewing your document” at completed and update the user when the decision lands.

​
What chmod checks

Document authenticity

Reads the printed data, the MRZ and the barcode, cross-checks them against each other, and detects digital manipulation, physical tampering and photocopies.

Liveness

Confirms a real, present person — not a photo, a video or a mask — and reports facial attributes with confidence for each.

Face comparison

Matches the document face to the selfie, and both to the face enrolled on the customer’s first verification.

Device integrity

Root and jailbreak, emulators, developer mode, VPN and proxy, spoofed GPS. You decide whether each one rejects, warns or is ignored.

Data matching

Compares the extracted name, date of birth, document number and more against values you already hold — fuzzy where it should be, exact where it must be.

Customer history

Flags a date of birth or document number that contradicts what the same customer presented before, and points at the transaction it conflicts with.

​
Three verification types

Every transaction has a type, and the type decides what the user is asked to do and what the result proves. See Verification types for how to choose.

​
Rules you control

On top of the type, each transaction carries a configuration. Every field has a default, so you set only what matters to you:
  • Which documents — by country and type, with per-document control over expiry.
  • How strict — liveness and face-match thresholds, expected age range.
  • What must match — names by similarity score, dates and numbers exactly.
  • How to treat the device — reject, warn or ignore for each integrity signal.
See What you can configure.

​
Where to go next

Your first verification

One complete flow in five requests. Start here.

API Reference

Authentication, the three endpoints, errors.

Client SDK

iOS and Android integration, configuration and theming.

​
Getting access

chmod is available to businesses through an account. Your chmod account manager provides the API host, the OAuth credentials for your backend and access to the SDK packages. Contact them to get started, or use the support link above. See the API Reference for what you receive and where to start.