Skip to main content
The Partner Onboarding API verifies your end customers’ identity. You create a customer, upload their documents, and the verification result comes back asynchronously. Endl handles the verification provider; you only work with the endpoints here.
A successful response body is the data object — there is no { data, code, message, status } wrapper. Errors use one five-key envelope, { code, message, status, data, errors[] }, for every status code, and every onboarding error carries its own ERRCUS_* code. See Errors and lifecycle.

​
userId is a reference id, not a UUID

Every customer id this API returns is a cus_-prefixed reference id — cus_PWEhqXkPKpWXiFd96jGq. The internal UUID is never exposed: a response filter rewrites it before the body leaves the server. That id is what create returns and what goes in every /api/v0/customer/{userId} URL.
The individual’s verification-provider applicant id is no longer returned — sumsubApplicantId has been removed from every response. A business still returns companyApplicantId and each beneficiaries[].applicantId, which is the uboRef for that owner’s document uploads.

​
Two customer types, the same endpoints

There is also an import path: if you have already verified the customer elsewhere, pass a shareToken instead of the full payload.

​
Base URL

Every endpoint lives under /api/v0/customer.

​
Authentication

One header. There is no login step and no secret to send.
A missing or invalid key returns 401 with ERRCORE_1004. A key without the customers permission returns 403 with ERRCORE_1005 on every call.

​
Fields that are not part of the contract

currency itself is returned by get and update.

​
Content types

​
application/json
Create and update take application/json; any other body type returns 415. Get, list, kyc-link and delete take no body and accept any Content-Type.
​
multipart/form-data
A file part named document, plus text form fields.

​
Rate limiting

The limit is set per API key: 60 requests per minute unless a different limit is configured for your account. Exceeding it returns 429 and the request is not processed — retry in the next minute window.

​
Correlation id

Every response carries an X-Request-ID header, except a 401 authentication failure, which carries none. Log it, and quote it when reporting a problem so the backend can trace that exact request.

​
Validate everything, then create

On create the whole payload — identity, questionnaire and custom fields — is validated before anything is written. If a single field is wrong the request is rejected with 400 and nothing is created. It is all-or-nothing, so a failed create leaves no partial customer behind. All field, questionnaire and custom-field errors come back together in errors[], each with its own ERRCUS_* code and the offending field. Duplicate email (ERRCUS_1600), duplicate phone (ERRCUS_1601), restricted country (ERRCUS_1605) and a reused share token are checked afterwards, one at a time, and only once the fields are valid. This applies to create and update. On update the questionnaire can’t be sent at all (400 ERRCUS_1303). An update must carry at least one updatable field with a non-blank value — otherwise it is 400 ERRCUS_1502.