The two-phase flow
Submit the application
Submit a single onboarding application referencing those persons as authorities, attaching per-person consents and evidence files.
pending for compliance review.
Persons vs. customers
A person (per_...) is a party — natural or legal — that you create. A customer is formed once an application is approved, establishing an active relationship with us; your persons are granted the requested authority over the customer and are linked to any provisioned accounts.
You don’t create customers directly. Submit an application and we provision the customer and accounts on approval.
What’s in scope
| Resource | Prefix | Created by |
|---|---|---|
| Person | per_ | You, via POST /persons |
| Person claim | clm_ | You, via POST /persons/{person_id}/claims |
| Onboarding application | onba_ | You, via POST /onboarding-applications |
| Customer | cus_ | Us, after application approval |
A complete example
Individual end-to-end. For a business, create a person for the legal entity plus each director / shareholder, and include arelationships claim on the legal person.
Upload evidence files
Upload the passport and selfie via the Files API; hold onto the returned file IDs.
Wait for compliance review
You’ll get back
status pending with no outcome yet. Poll GET /onboarding-applications/{id} for updates — the customer and accounts appear once compliance approves.Every consent here except
data_accuracy references a legal_document_version. data_accuracy is an attestation — omit the field. List valid document versions via the legal document versions endpoint. See required consents for the full breakdown.Where to next
Persons
Natural and legal persons, built from claims.
Claims
Claim types, schemas, and lifecycle.
Applications
Authorities, consents, evidence, and duplicates.
Errors
Every validation error and how to fix it.