vendor_data flows into the same profile — you get a single pane of glass for identity, risk, and compliance for each person.
What lives on a User
| Category | Fields / objects |
|---|---|
| Identity | vendor_data, uuid, display_name, full_name, date_of_birth, portrait_image |
| Status | ACTIVE, FLAGGED, BLOCKED |
| Session aggregates | session_count, approved_count, declined_count, in_review_count, features map |
| Verified contact | approved_emails[], approved_phones[] |
| Geography | issuing_states[] (from verified ID documents) |
| Activity | first_session_at, last_session_at, last_activity_at |
| Biometrics | Attached face records (for search / duplicate detection / blocklist) |
| Documents | ID documents, proofs of address, selfies from sessions |
| Relations | Linked Business entities (if the user is a director / UBO of businesses verified on your app) |
| Metadata | Arbitrary JSON for your own data |
When a User is created
Automatically — on first session with a new vendor_data
The typical case. You call
POST /v3/session/ with a vendor_data value Didit has never seen. A User entity is created in ACTIVE status and linked to that session.Explicitly — via POST /v3/users/create/
You pre-create the User before any session runs. Useful for seeding metadata, setting initial status, or bulk-onboarding customers from an existing database.
What you can do
| Operation | How |
|---|---|
| List users | GET /v3/users/ with filters (status, date, country) |
| Get user | GET /v3/users/{vendor_data}/ |
| Create user | POST /v3/users/create/ |
| Update profile | PATCH /v3/users/{vendor_data}/ |
| Change status | PATCH /v3/users/{vendor_data}/update-status/ |
| Delete users | POST /v3/users/delete/ (batch) |
| Attach / search faces | Console + Lists API for blocklists |
| View documents | Via session decisions |
| Add to blocklist | Console + Lists API |
| Review KYC history | GET /v3/sessions?vendor_data=... |
| Review transactions | GET /v3/transactions/?vendor_data=... |
| Import / export | Console only (CSV) |
| Manage in console | Full UI walkthrough |
Users and Businesses
A single User can be linked to one or more Businesses — for example, when the same person is a director of one company and a UBO of another. Didit preserves these links automatically when KYB identifies people from company registries.User ↔ session relationship
The User aggregates the latest state of each feature across all sessions. A failedaml check on the most recent session will show up in the User’s features.aml field even if older sessions approved.
Next steps
Data model
Every field, type, and index.
Operations
Create, update, change status, delete.
Faces & biometrics
Attach a face for search and blocklisting.
Blocklist
How blocklisting works for users.
KYC history
Every session tied to the user.
Console
Full Users UI walkthrough.