| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Overview
This method is used by partners to import applicant profiles for Copy Applicant.
Webhook behavior during import
On import, the applicant inherits the Donor's review status, and status webhooks fire accordingly:
- Initial webhook — fired immediately with the Donor's inherited status (for example,
applicantReviewed/GREEN/Approved). This is expected: most clients want the inherited verdict right away. - Follow-up webhook — if the Recipient's target level requires steps the Donor did not complete (for example, Penny Drop, a custom questionnaire, a missing document), the applicant moves to
Pending/Documents Requested, firing a second webhook — often within the same second as the first.
To distinguish the two and filter out the inherited-status webhook if needed, consider the following:
- The initial webhook carries a
reuseScopefield; for Copy Applicant, it is set toimportApiShareToken. reuseScopeis only present on that initial webhook — never on later ones for the same review attempt.- If your integration should act only on your own level's checks (not the inherited Donor verdict), ignore or hold webhooks where
reuseScopeis present.
For the full reuseScope reference, see User verification webhooks.
NoteCopy Applicant supports both individual and company applicants, but it is enabled separately for each.
For companies, the full company structure is copied but linked profiles of individual beneficiaries are included only if the feature is also enabled for individual applicants on your account; otherwise, only the structure is copied without linked profiles.
Request example
curl -X POST \
'https://api.sumsub.com/resources/applicants/-/import?shareToken=_act-0b8a43f6-b70f-4ad3-bda9-7ce904589380' \
-H 'X-App-Token: <your-app-token>' \
-H 'X-App-Access-Sig: <your-signature>' \
-H 'X-App-Access-Ts: <unix-timestamp>'Response explained
In the response, a new applicant ID generated on the partner's side is returned.
{
"id": "5d08a63239b79354a2ebaa1d",
"createdAt": "2019-06-18 10:52:02",
"clientId": "CoolCoinLtd",
...
}Error response example
You may encounter two categories of errors:
- Generic token validation occurs first and may return a
401 Unauthorized. - If token validation succeeds, the endpoint may return a
400error with a specific error code indicating the underlying problem.
{
"code": 401,
"description": "Token is invalid: Token _act-374dc16e-4c7e-4e50-a621-ed76a0dd68fb-v2 is invalid now: created at Tue Dec 02 08:27:46 UTC 2025 with ttl 5 but accessed at Tue Dec 02 08:29:55 UTC 2025 [source: null]",
"type": "de.smtdp.commons.service.exceptions.ServiceException"
}{
"code": 400,
"errorCode": 10518,
"errorName": "copy-applicant-disabled",
"description": "Copying applicants is disabled for you",
"type": "de.smtdp.commons.service.exceptions.ServiceException"
}Error codes with descriptions
| Error code | Error name | Description |
|---|---|---|
| 10501 | not-in-partners-list | Reusing applicants is not allowed since the target is not your partner. |
| 10502 | invalid-partner-id | Partner ID extracted from the share token is invalid. |
| 10503 | invalid-share-token | Provided share token is malformed or expired. |
| 10504 | non-suitable-share-token | Share token is not suitable for reuse with the given level. |
| 10520 | copy-applicant-disabled | Copying applicants is disabled for you. |