> ## Documentation Index > Fetch the complete documentation index at: https://docs.etherfuse.com/llms.txt > Use this file to discover all available pages before exploring further. # Import a verified session > Import a verification the customer already passed on the partner's own Sumsub level, handed over as a share token. Prerequisites, and what does and doesn't transfer: [KYC Sumsub Shared Token](/guides/kyc-sumsub-shared-token). Answers **`200`**, not `202`: the import is committed before the response, which carries the same requirements breakdown as [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status). That breakdown covers the identity stage only. Send what it lists, then wait for `kyc_updated` and read the requirements again: `proof_of_address` and `customer_agreement` appear only when the customer reaches their stages. See [Requirements unlock in stages](/guides/onboarding#requirements-unlock-in-stages). **Only `shareToken` is accepted.** The verification level and the customer's identity are ours to decide. The token is a credential; it is never logged and appears in no response. No country is sent: it is read from the shared verification and used to route the customer. The customer's registered `userInfo.email` is required and is set on the imported applicant. **Nothing is trusted wholesale.** Everything imported is re-checked against Etherfuse's own requirements, so a session approved in the partner's account is not automatically approved here. **Importing again.** If the customer's verification has not reached review, a new import replaces it, for example after an earlier import left documents missing. Once the customer is approved, denied, or in review, the import returns `409`. ## OpenAPI ````yaml /openapi.json post /ramp/customer/{customer_id}/verification/import openapi: 3.1.0 info: title: Etherfuse FX API description: Partner-facing ramp API for onramps, offramps, swaps, and KYC. license: name: Proprietary version: 1.0.0 servers: - url: https://api.sand.etherfuse.com description: Sandbox security: - ApiKeyAuth: [] tags: - name: Authentication description: >- Partner JWT authentication — exchange a JWT for an access token, or launch a user into the app. - name: Lookup description: >- Public reference data: exchange rates, stablebonds, bond costs, country codes. - name: Assets description: Rampable stablecoins and stablebonds available per blockchain. - name: Bank Accounts description: Register and retrieve customer bank accounts. - name: Quotes description: Price quotes for onramps, offramps, and swaps. - name: Orders description: Create, track, and manage ramp orders. - name: Swaps description: Crypto-to-crypto swaps. - name: Sponsored description: Token approvals for sponsored (gasless) offramps. - name: Customers description: Customer (child-organization) records. - name: Wallets description: Register and manage customer wallets. - name: KYC description: >- Submit a customer's verification data, documents and questionnaire answers, import a verification they already passed elsewhere, and check where their KYC stands. - name: Webhooks description: Event notification subscriptions. - name: Organizations description: Organization identity, child orgs, and partner fees. - name: Statements description: >- Monthly revenue share statements for closed months, as a list or as a CSV or PDF download. - name: Deprecated description: >- Endpoints kept working until their sunset date and then removed. See the deprecations page for replacements and dates. paths: /ramp/customer/{customer_id}/verification/import: post: tags: - KYC summary: Import a verified session description: >- Import a verification the customer already passed on the partner's own Sumsub level, handed over as a share token. Prerequisites, and what does and doesn't transfer: [KYC Sumsub Shared Token](/guides/kyc-sumsub-shared-token). Answers **`200`**, not `202`: the import is committed before the response, which carries the same requirements breakdown as [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status). That breakdown covers the identity stage only. Send what it lists, then wait for `kyc_updated` and read the requirements again: `proof_of_address` and `customer_agreement` appear only when the customer reaches their stages. See [Requirements unlock in stages](/guides/onboarding#requirements-unlock-in-stages). **Only `shareToken` is accepted.** The verification level and the customer's identity are ours to decide. The token is a credential; it is never logged and appears in no response. No country is sent: it is read from the shared verification and used to route the customer. The customer's registered `userInfo.email` is required and is set on the imported applicant. **Nothing is trusted wholesale.** Everything imported is re-checked against Etherfuse's own requirements, so a session approved in the partner's account is not automatically approved here. **Importing again.** If the customer's verification has not reached review, a new import replaces it, for example after an earlier import left documents missing. Once the customer is approved, denied, or in review, the import returns `409`. operationId: import_verification parameters: - name: customer_id in: path description: >- The customer (child org) ID. Must belong to the caller's organization or a direct child. required: true schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/ImportVerificationRequest' responses: '200': description: >- The session was imported. `requirements` lists what is still outstanding. If we could not read the requirements, we leave the field out; read `GET /ramp/customer/{customer_id}/kyc?requirements=true` instead. content: application/json: schema: $ref: '#/components/schemas/ImportVerificationResponse' '400': description: >- The message carries the detail. Any of: `shareToken` missing; `additionalInfo.curp` is not 18 letters or digits (nothing is created and the share token is not spent); the share token is expired, already spent, created for someone else, or shares nothing our requirements ask for; the shared verification has no country on file, or one we cannot verify (nothing is created and the share token is not spent); the customer has no email on file; or the customer is a business account. content: text/plain: schema: type: string example: >- The verification session could not be imported: share token has expired '404': description: >- No organization exists with that `customer_id`, or it is not a customer of your organization. '409': description: >- Any of: this customer's verification is approved, denied, or in review, so a new session cannot replace it; or our verification provider won't let a new session replace this customer's verification. Nothing was imported and the share token was not spent. Don't retry the second case; contact us. content: text/plain: schema: type: string example: >- This customer's verification is approved, denied, or in review; a new session cannot replace it '502': description: >- Usually we could not reach our verification provider before the import, nothing was imported, and you can retry. If the retry returns a `400` saying the share token was already used, the first import may have landed: contact us with the `customer_id`. content: text/plain: schema: type: string components: schemas: ImportVerificationRequest: type: object description: >- A verification session the partner already completed with the same provider, handed over as a share token they created for us. No other fields are accepted. required: - shareToken properties: shareToken: type: string description: >- The single-use, short-lived share token created for the verified applicant, targeting Etherfuse's client id. example: _act-sbx-jwt-eyJhbGciOi... additionalInfo: type: object description: >- Information a shared session does not bring across. Custom fields on your own verification level are not copied when you share an applicant. properties: curp: type: - string - 'null' minLength: 18 maxLength: 18 pattern: ^[A-Za-z0-9]{18}$ description: >- The customer's CURP. A Mexican customer (`country: "MEX"`) needs one to complete verification. We check it before the share token is spent and store it on the imported verification. Send it here, or the customer enters it in the [`/idv` launch](/guides/kyc-websdk). example: XEXX010101HNEXXXA4 ImportVerificationResponse: type: object description: The outcome of importing a verification session. required: - customerId - status properties: customerId: type: string format: uuid status: type: string enum: - not_started - in_progress - submitted - approved - denied requirements: type: array description: >- What is still outstanding after the import: the same breakdown `GET /ramp/customer/{customer_id}/kyc?requirements=true` returns. Left out if we could not read the requirements after the import. items: $ref: '#/components/schemas/RequirementState' example: customerId: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: in_progress requirements: - type: personal_data status: satisfied requiresLaunch: false - type: identity_document status: satisfied requiresLaunch: false - type: occupation status: pending requiresLaunch: false - type: selfie status: satisfied requiresLaunch: true - type: customer_agreement status: pending requiresLaunch: false RequirementState: type: object description: One thing a customer's verification still needs, and where it stands. required: - type - status - requiresLaunch properties: type: type: string description: >- Which requirement this is. Only the ones that apply to this customer are listed; their country decides which those are. 1. `personal_data`: name, date of birth, tax ID, country and address; Mexico also requires CURP 2. `identity_document`: a government-issued ID 3. `proof_of_address`: an address document; appears only when the identity document carried no address 4. `occupation`: job title and occupation category 5. `selfie`: a live face capture; cannot be uploaded 6. `customer_agreement`: the customer accepting the required agreements We reserve the right to add requirements, and will update these docs when we do. A country may also introduce one of its own; see [Country-specific requirements](/guides/onboarding#country-specific-requirements). enum: - personal_data - identity_document - proof_of_address - occupation - email_confirmation - selfie - customer_agreement status: type: string description: >- How far along this requirement is. - `satisfied`: accepted, nothing more to do - `pending`: nothing has been provided for this yet, so it is still owed - `awaiting_review`: provided, not yet reviewed - `action_required`: **reviewed and rejected**, so it must be provided again, corrected `pending` and `awaiting_review` are the distinction that matters: a shared verification whose identity document and selfie transferred reads `awaiting_review` for both, so do not read `pending` into it and re-send. Treat this as an **open set**: more values may be added, so key your logic off the two that carry an instruction (`satisfied` means done, `action_required` means re-send) and treat anything else as in flight. enum: - satisfied - pending - awaiting_review - action_required requiresLaunch: type: boolean description: >- True when only the customer can satisfy this in the hosted step, such as the liveness capture. A property of the requirement rather than of its progress, so it does not change as the customer advances. `selfie` reads true whether or not the selfie has been taken. A requirement with status `satisfied` needs no further action even when this flag is true. False does not mean the requirement is yours to submit. It means the API *can* submit it. The customer can always enter it in the hosted step instead, which is why launching them satisfies everything. So this flag says what the API cannot reach, not when to launch: an outstanding requirement reading true is one no API call will ever clear. example: type: identity_document status: pending requiresLaunch: false securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: API key sent in the Authorization header. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.