Skip to main content
chmod has two first-class objects. A customer is a person. A transaction is one attempt to verify that person. Everything else — configuration, tokens, results, webhooks — belongs to one or the other.

​
Customers

A customer is created once and identified by a customer_id you store against your own user record. When you create one you give chmod your own identifier for the person, and optionally an email and a phone number.

​
What chmod accumulates per customer

The customer record grows with each successful verification, and that growth is where a large part of chmod’s value sits:
  • An enrolled face. The liveness capture from the first successful biometric transaction becomes the reference face. Every later transaction compares the new selfie against it. This is the check that catches one person opening several accounts under different names.
  • Document history. Document numbers, dates of birth and names extracted in earlier transactions. A later document that disagrees — a different date of birth, a different number for the same document type — is flagged, with a pointer to the transaction it conflicts with.
Neither exists on a customer’s first transaction. That is expected, and chmod says so with an informational finding rather than a rejection.
Creating a fresh customer for every verification throws all of this away. Every transaction becomes a first transaction, and the identity checks never run. Store customer_id once and reuse it for as long as that person exists in your system.

​
Customer status

chmod maintains a status on every customer, and it participates in every analysis:

​
Transactions

A transaction is one verification attempt.

​
Configuration is per transaction

There is no account-level configuration. Every transaction carries its own rules, so a strict onboarding check and a light step-up check can run from the same integration without touching any shared setting. Once a transaction is created its rules are fixed — to change them, create a new transaction.

​
Lifecycle

Finished, failed and expired are terminal. A transaction is never reopened or re-run; a retry is a new transaction for the same customer. See How verification works for the full sequence.

​
What to store on your side

You do not need to store the full result — it can be fetched again by id — and there are good reasons not to: it contains document images and personal data. Store what you act on, and fetch the rest when you need it.