Skip to main content
If you already verified a customer on your own Sumsub level, hand that verification to Etherfuse instead of putting the customer through it again. You create a share token, we import the session, and the customer’s identity data, documents and liveness come with it. The customer only completes requirements that the shared session or your API submissions did not satisfy.
This page names the underlying verification provider because the shared-token flow cannot be described without it: you create the share token in your own account with that provider. Elsewhere the docs keep the provider abstract.

​
Prerequisites

Reusable KYC is off by default on both sides. Before any of this works:
  1. You verify customers on your own Sumsub level.
  2. A one-time data-sharing agreement is signed with Sumsub, by both parties.
  3. Etherfuse is added as a sharing partner in your Sumsub dashboard, and you in ours.
  4. The account creating share tokens holds the “Share applicants data” permission.
Talk to your Etherfuse contact to start this. Neither side can enable it unilaterally.

​
The flow

1

Create the customer's organization

A personal org, as in any other flow. See KYC WebSDK. Send userInfo.email: the import uses it.
2

Create a share token in your Sumsub account

For the applicant you already verified, targeting Etherfuse’s client id. Share tokens are short-lived and single-use.
3

Import the session

POST /organization/{organizationId}/verification/import
4

Push what the import response lists as pending

Usually the occupation answers, through POST /organization/{organizationId}/verification/questionnaire, and any region-specific document through POST /organization/{organizationId}/verification/documents. Send only these. When the last one lands, the identity stage is submitted for review.
5

Wait for the next stage

A kycUpdated webhook arrives when the stage is submitted, and again when the review clears and the next stage arrives (status back to inProgress). Then read GET /organization/{organizationId}/kyc?requirements=true.
6

Push the later stages as they appear

proofOfAddress appears only if the identity document carried no address and the shared session did not include one. customerAgreement appears last; send it only if you are forwarding the customer’s acceptance. Repeat the previous step after each one.
7

Launch the customer for what remains

Any questionnaire you did not answer over the API, plus liveness if the shared session did not cover it. The customer also accepts the customer agreement in /idv unless you forwarded it.
Do not send everything at once after the import. The import response lists only the stage the customer is on. The customer agreement belongs to a later stage, and it is not in the list yet. An agreement sent together with the occupation answers is accepted with a 202, then refused in the background. See Requirements unlock in stages.

​
Importing

200 OK
This response describes the identity stage only. proofOfAddress and customerAgreement are not listed yet, even when the customer will need them.

​
What carries across

Nothing is trusted wholesale. Everything imported is re-checked against Etherfuse’s own requirements. A session approved in your account is not automatically approved in ours.

​
Error handling

The endpoint’s full response codes are on its API reference page. Errors are problem details; the messages below appear in detail. Requirement and overall statuses are in Tracking verification status.

​
Sandbox

Testing this end to end needs a second sandbox account acting as the donor, with the same sharing configuration as production. Without one, build the rest of your integration against KYC API and add the import once sharing is in place. See Test environment.