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.

​
Next steps

Hosted verification links

The route with no eligibility constraints.

Troubleshooting

Tracking linkage and resolving failures.