Skip to main content
If you already run KYC in your own Sumsub account, you can forward that verification to Venly instead of putting the user through a second flow. You pass a Sumsub share token when creating the account, and Venly redeems it against your verification tenant.

​
Three conditions, all required

This route is deliberately narrow. All of these must hold, or the request is rejected:

Individuals only

partyType must be INDIVIDUAL. KYC only — there is no KYB equivalent.

Self-custody only

Your company’s wallet type must be SELF_CUSTODY.

Tenant provisioned

Verification must be provisioned for your company.
If any of these rule you out, use a hosted verification link instead — it has none of these constraints.

​
Only at account creation

The token is accepted only on the inline party of POST /accounts:
Note the shape: it goes on the inline party object, not at the top level, and you must create the party inline. There’s no way to attach a token to a party you created earlier, and no way to attach one to an existing account. Sending it to POST /parties instead is rejected with 400 sumsub-token-not-supported. The field is write-only: never persisted, never returned in any response.

​
The whole request rolls back on failure

The token is forwarded inside the same transaction that creates the party, account, and wallet. If the forward fails, nothing is persisted — no party, no account, no wallet. That’s deliberate, and it makes your retry logic simple:
On failure, get a fresh token and resubmit the entire request. You never have to check what was partially created, reconcile a half-built account, or clean up an orphaned party.

​
Errors

Every one of these rolls the transaction back, so a retry is always a clean, full resubmit.

​
Mint the token late

Share tokens are single-use and short-lived. Mint the token immediately before the account-creation call rather than caching it — a token minted earlier in a user session has likely expired by the time you use it, and that surfaces as SUMSUB_TOKEN_NOT_REDEEMABLE.
This is the most common failure with this route. If you’re seeing it intermittently, look at how long your token sits between minting and use, not at the Venly call. Because retries need a fresh token, the resilient shape is: mint → submit → on failure, mint again → submit again. Don’t retry the same body.

​
After it succeeds

The account is created and the verification is registered against your tenant. From there it behaves exactly like the hosted route: the verdict is applied asynchronously to the party’s kycStatus, and you observe it via Get a party or a webhook. Forwarding a token is not itself a verdict. A successful 201 means the verification was accepted for processing, not that the party is VERIFIED.

​
When the customer still has to finish

A forwarded verification isn’t always complete. If the applicant never finished their checks in your Sumsub flow, the verification waits on them — and without action it would stay pending indefinitely. The 201 tells you straight away. It carries a verification block with what’s missing and a link to hand to your end customer:
Send the customer to completionUrl. It’s short-lived and embeds an access token, so treat it as a credential. When no action is required, the block is absent.
The verification block appears only on this create response. It’s never stored, never returned by a later read, and absent when the request replays an earlier submission. Don’t rely on getting it a second time — use the endpoints below to follow up.
To follow up later — the link expired, or the customer came back days afterwards:
1

Check where it stands

GET /parties/{partyId}/kyc-status returns the verificationState, the requiredAction and the outcome of each step. AWAITING_CUSTOMER means it’s waiting on your end customer; IN_REVIEW means they’re done and it’s with the reviewer.
2

Mint a fresh link

POST /parties/{partyId}/kyc-status/completion-link issues a new short-lived link. Call it each time you need one. A verification that isn’t waiting on the customer answers 409 kyc-not-completable.
The verdict still lands on the party’s kycStatus as usual. The KYC status endpoint shows the progress towards it.

​
Next steps

Hosted verification links

The route with no eligibility constraints.

Get a party's KYC status

See what a stalled verification is waiting on.

Troubleshooting

Tracking linkage and resolving failures.