Reusable KYC via API
Enable secure reuse of existing KYC data via API.
Reusable KYC via API will always recheck applicant data to make sure it meets the recipient level requirements. It is recommended for clients requiring a regulatory compliant KYC on the recipient side.
Tip
If needed, you can copy applicant data without rechecks with the Copy Applicant solution.
Once clients agree to share verification data, they become the donor and recipient. You can have an unlimited number of sharing partners, and Sumsub also supports bidirectional sharing.
How Reusable KYC via API works
Our Reusable KYC via API solution uses a share token based approach to transfer verified applicant data from the donor to the recipient. Upon receipt, all shared data is always rechecked against the specific level settings and requirements of the recipient.
For example, the identity document will be rechecked to ensure it matches the accepted document type, remains valid (i.e., not expired), and, if required by the recipient’s verification level, applicable AML checks are run again.This approach guarantees that this will count as a KYC for the recipient by regulatory standards and meets the specific compliance requirements of our clients.
Only applicant data that is reusable under the recipient’s verification level settings is transferred, ensuring full compliance with end-user data privacy. Three main cases:
- Approved applicant. If the donor applicant profile contains enough data to meet requirements of all recipient verification steps, the system completes all checks and assigns the applicant an Approved status.
- Documents requested. If the donor applicant profile contains data that meets some, but not all of the requirements of recipient verification steps, then the applicant will be assigned with a Documents requested status to fulfill the remaining steps at a later point.
- No applicant created. In the case the applicant data from the donor meets none of the requirements of the recipient verification steps, an applicant will not be created and no data will be copied. We will return an error with information on why no data was transferred.
Note
We do not require Liveness check for Reusable KYC via API. If the provided recipient’s verification level includes a liveness step, the system reuses the selfie from the donor applicant profile to perform the check again.
If no selfie is available, the system sets the applicant status to
documents requested
, so the applicant can complete liveness at a later point.
Reusable KYC via API involves the following steps:
- Donor generates a new share token for a specific applicant. To generate a share token, use this API method:
curl --request POST \
--url https://api.sumsub.com/resources/accessTokens/shareToken \
--header 'content-type: application/json' \
--data '
{
"applicantId": "63e092c51b7b4030f2e01154",
"forClientId": "CoolCoinLtd",
"ttlInSecs": "600"
}
'
Name | Type | Required | Description |
---|---|---|---|
applicantId | String | Yes | Applicant ID in donor company. |
forClientId | String | Yes | Client ID for recipient. You can find your clientId in the Dashboard in the applicant profile (field Created for) and in the response (field clientId ). |
ttlInSecs | Integer | No | Time to live in seconds. Default 1200 . |
Response
A new share token is returned.
{
"token": "eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTZmODI2ZTU0LTE2MzctNDViMS05NzMyLWY1MjZiN2YxNWE3YyIsInVybCI6Imh0dHBzOi8vYXBpLnN1bXN1Yi5jb20ifQ.",
"forClientId": "CoolCoinLtd"
}
Info
Make sure your integration code does not validate or analyze the access token content, as the format is not fixed and may undergo further changes in the future. The token must be treated as an arbitrary string with the maximum length of 1KB.
- Donor passes the share token to the recipient.
- Recipient includes the share token when using this API method to attempt to reuse verification data from the donor.
curl -X POST \
'https://api.sumsub.com/resources/api/reusableIdentity/reuse?shareToken=_act-jwt-eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTE3YjM5YTljLWRhOWUtNGY2MS04Y2ZjLTYwNzViNWM2NDk5MSIsInVybCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA5MCJ9.&levelName=liveness-id-poa'
Name | Type | Required | Description |
---|---|---|---|
shareToken | String | Yes | A token used to access the shared KYC data. |
userId | String | No | External user identifier. |
levelName | String | Yes | The name of the level on the recipient's side for which the KYC data is being reused. |
Response
If at least one document or part of the applicant’s data meets the requirements of the recipient’s level, the system creates an applicant on the recipient side and reuses all eligible documents. In this case the applicant profile data will be returned:
{
"id": "689223ed75b5d1bc2bb38gdg",
"createdAt": "2025-08-05 15:31:57",
"key": "UUBSGJZXJDFXXW",
"clientId": "DonorCompany"
…
}
If no documents meet the recipient’s level requirements, the system returns an error message and does not create an applicant. See this article for the full list of possible errors.
{
"code": 400,
"errorCode": 10513,
"errorName": "reusable-kyc-not-compatible-doc-type",
"description": "Not Reusable KYC for level: id-liveness-preview",
"type": "de.smtdp.commons.service.exceptions.ServiceException"
}
Note
We support reuse of identity documents, PoA documents, and liveness data. Questionnaire and applicant data reuse is not yet supported, but this functionality is planned for a future release.

Enable Reusable KYC for API
The following is a sequence of steps to be taken to turn on the data-sharing functionality.
Step 1: Sign contract
Contact our support team at [email protected] so that the donor and recipient can each sign a one-time contract to use the service. You will not have to sign any additional documents.
Step 2: Add sharing partners
Once the service is enabled, you can add sharing partners directly in the Dashboard. For more instructions, see this article.
Step 3: Use share token
Implement the share token approach as described here.
How to test Reusable KYC via API using Preview
To simplify integration testing, use this API method to simulate the Reusable KYC via API flow. This method performs validation and preview logic only—it does not create applicants or transfer any data. You can use this method with production data.
curl -X POST \
'https://api.sumsub.com/resources/api/reusableIdentity/reuse/preview?shareToken=_act-jwt-eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTE3YjM5YTljLWRhOWUtNGY2MS04Y2ZjLTYwNzViNWM2NDk5MSIsInVybCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA5MCJ9.&levelName=liveness-id-poa'
This method allows you to verify that your integration is correctly set up to handle all possible responses, create applicants, and reuse documents appropriately. The method utilises the same query parameters and follows the same requirements as the live flow.
How to test Reusable KYC via API in Sandbox
You can test Reusable KYC via API in Sandbox mode without the need to create a new level. Switch to the Sandbox as described here and use your existing level.
Before sharing agreements are set up, you can test sharing using Reusable KYC within the same key, which means your client key is both the donor and recipient.
The following is a sequence of steps to be taken to test the share token based implementation of the Reusable KYC via API in Sandbox.
Step 1: Create applicant
Create an applicant in Sandbox in your chosen level. Make sure the applicant is approved, has reusable documents, and meets the requirements of the level you want to test with.
Step 2: Generate share token
Generate a share token for the applicant using one of the following methods:
- Use this API method. Make sure to include an app token configured for the Sandbox environment in the request.
- In the Dashboard, go to the Applicants page and select the applicant of interest. In the drop-down menu on the top of the page, click Generate share token.
Step 3: Reuse applicant via API
Use this API method and include an app token configured for the Sandbox environment in the request.
This should now trigger the Reusable KYC via API flow and create an applicant. You can reuse any documents with your client key acting as both the donor and recipient.
Updated about 3 hours ago