customer_id, and reuse it for every
transaction that person ever runs.
Reusing
customer_id is what enables face comparison against the enrolled face and
consistency checks against previously extracted document data. Creating a new customer
per verification silently disables both.Request
string
required
Bearer {access_token} — see Authentication.string
required
Your own identifier for this person — a user id, an account number, whatever you key on.
Returned back to you on the response and useful for reconciliation.
string
The person’s email address. Optional.
string
The person’s phone number in E.164 format, for example
+5491122334455. Optional.string
A photo of the person’s face. Optional. When provided, the customer is created with an enrolled reference face, which is treated as valid. Later transactions compare the captured face against it.Send the plain base64 of the image file: standard alphabet, without a
data:image/...;base64, prefix and without line breaks. JPEG or PNG only, up to 4 MB before encoding. Other formats, such as HEIC or WebP, are rejected.Response
string (UUID)
The chmod identifier for this person. Persist this.
string
Echoed back from the request.
string (ISO-8601)
When the customer was created.
Example
Response
Errors
A400 on this endpoint means nothing was created. See Errors for the response body.
Customer status
Every customer carries a status that chmod maintains, and it participates in the analysis of every transaction:Next
Create transaction
Open a verification for this customer and get the SDK token.

