Every onboarding call uses the user’s bearer token (
Authorization: Bearer <access_token>)
from authentication.How it works
- Create an application once with
POST /v1/applications, passingisCompanyto pick the individual or company flow. - Poll
GET /v1/applicationsand readstatus.currentStep. The reference app polls about once a second. - Show the screen for that step. Some steps need input from the user (a form, the Sumsub check, accepting terms); others just wait while we process. The step advances on the next poll once the work is done.
- When
currentStepisnull, onboarding is finished. Send the user into the app.
After approval: from application to customer
Approval turns the applicant into a customer, and that hand-off gives you everything the rest of the API needs:- The application object (from
GET /v1/applications) carries thecustomerId— every customer-scoped endpoint takes it. - The customer’s primary account is created automatically — you don’t call anything.
Fetch it with List accounts; the
accountIdfrom that response is what cards, payments, and beneficiaries hang off.
currentStep: null is simply: read customerId from the
application → GET /v1/customers/{customerId}/accounts → build the app around
the returned accountId.
The server decides the order, so you don’t hard-code the sequence. Render whatever
currentStep comes back, and treat values you don’t handle as “keep polling”, since new
sub-states get added over time.
Steps
currentStep | Meaning | What to do |
|---|---|---|
KYC_INTERNAL | Our own KYC form. | Get the schema, render it, submit the answers. |
KYC_SUMSUB | Sumsub identity check. | Get a Sumsub token and run the SDK. |
RISK_IN_PROGRESS | Risk check running. | Show a loader and keep polling. |
RISK_COMPLIANCE_REVIEW | Awaiting backoffice compliance review. | Show a read-only “in review” screen and keep polling. |
RISK_COMPLIANCE_REVIEW_RFI | Compliance requested information from the program. | Show a read-only “in review” screen and keep polling. Program owners see the RFI reason in backoffice CSV reports. |
RISK_COMPLIANCE_REJECTED | Risk compliance rejected (terminal). | Show a contact-support screen and stop polling. |
LEGAL_AGREEMENTS | Terms to accept. | Accept the agreements. |
HOLDER_CREATION_IN_PROGRESS / ACCOUNT_CREATION_IN_PROGRESS | Account being created. | Show a loader and keep polling. |
null | Finished. | Send the user into the app. |
Waiting and failure states
Other values are review or failure states. Render the matching screen:currentStep | Meaning | What to do |
|---|---|---|
KYC_INTERNAL_PARTIAL_DATA / KYC_INTERNAL_VALIDATION_ERRORS | The form needs more or corrected input. | Re-render it with the errors. |
KYC_SUMSUB_AWAITING_PROVIDER_APPROVAL / KYC_SUMSUB_KYC_VERIFICATION | Submitted to Sumsub, waiting on the result. | Show a loader and keep polling. |
KYC_INTERNAL_COMPLIANCE_REVIEW / KYC_SUMSUB_COMPLIANCE_REVIEW | Manual review. | Show a read-only “in review” screen. |
KYC_DECLINED / KYC_FAILED / KYC_ERROR / ACCOUNT_CREATION_FAILED | Failed. | Show the matching error screen and stop polling. |
Companies (KYB)
Create the application withisCompany: true and the flow is the same, except the KYC steps
become KYB steps: KYB_INTERNAL and KYB_SUMSUB in place of KYC_INTERNAL and
KYC_SUMSUB. You fetch the form from the same schema endpoint
(it returns company and beneficial-owner fields), but you submit the answers to
POST /v1/applications/kyb instead of the individual KYC endpoint.
One extra waiting state can show up:
currentStep | Meaning | What to do |
|---|---|---|
KYB_INTERNAL_AWAITING_UBOS | Waiting on the company’s beneficial owners to verify. | Show an “awaiting UBOs” screen and keep polling. |