Customer API
The Customer API is how a Company's backend works with stored records after verification — reading history, correcting data, driving state changes, and managing assignments. It is available on the Stored tier (there are no records to manage on the session-based tier).
API reference
The complete Customer API — Customers, Digital Identities, and Assignments — is published as an interactive reference with every endpoint, request and response schema, parameter, and status code, rendered directly from the service's OpenAPI specification.
Open the Customer API reference
Resources
| Resource | Description |
|---|---|
| Customer | The master record for a person: personal data, address, custom fields, and links to Digital Identities. |
| Digital Identity | A single verification attempt and its result (read-only except for state transitions). |
| Assignment | A link between a Customer and something they were issued — see Assignments. |
Common operations
| Operation | Illustrative call |
|---|---|
| Read a Customer | GET /v1/customers/{id} |
| List / filter Customers | GET /v1/customers?… (non-PII filters) |
| Search by personal data | POST /v1/customers/search (PII in the body) |
| Update fields | PATCH /v1/customers/{id} |
| List a Customer's identities | GET /v1/customers/{id}/identities |
| Read one identity | GET /v1/customers/{id}/identities/{identityId} |
| Transition an identity state | POST /v1/customers/{id}/identities/{identityId}/transition |
| Anonymize a Customer (GDPR) | DELETE /v1/customers/{id} |
| Discover the schema | GET /v1/customers/schema |
Search that includes personal data uses POST … /search with the query in the request body rather than in the URL, to avoid leaking PII into logs and proxies.
Custom fields
Beyond the typed base fields (name, date of birth, address, and standard identity fields), a Customer carries a free-form custom_fields object for Company-specific extension data. No schema declaration is required to write custom fields; keys a Company wants to search on are registered separately as indexed fields. GET …/schema reports the typed base fields and their flags.
Writing safely around active verifications
Some Customer fields are owned by the verification workflow (identity anchors, primary identity, decision). While a workflow is running for a Customer:
- editing a workflow-managed field returns
409 Conflictwith the active session; retry once it completes; - editing integrator-managed fields (custom fields, references, preferences) always succeeds.
This keeps the workflow authoritative over identity data while leaving operational fields writable at any time.
Who can write
The Customer API is one of three writers to the record store, alongside verification workflows and the back-office UI. All writes are authenticated (OAuth2) and audited.