> ## 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). **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 `user_info.email` is set on the imported applicant, so the email step confirms that address rather than one the customer types in. **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. ## 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: 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). **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 `user_info.email` is set on the imported applicant, so the email step confirms that address rather than one the customer types in. **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. 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` describes what is still outstanding. content: application/json: schema: $ref: '#/components/schemas/ImportVerificationResponse' '400': description: >- The message carries the detail. Any of: `shareToken` missing; the token is expired, already spent, minted 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 token is not spent); the customer has no email on file; the customer is a business account; or the `customer_id` exists but is not a child of your organization. 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`. '409': description: >- This customer's verification has already started; a session can only be imported before verification begins. content: text/plain: schema: type: string example: >- This customer's verification has already started; a session can only be imported before verification begins components: schemas: ImportVerificationRequest: type: object description: >- A verification session the partner already completed with the same provider, handed over as a share token they minted for us. No other field is accepted. required: - shareToken properties: shareToken: type: string description: >- The single-use, short-lived share token minted for the verified applicant, targeting Etherfuse's client id. example: _act-sbx-jwt-eyJhbGciOi... ImportVerificationResponse: type: object description: The outcome of importing a verification session. required: - customerId - status - requirements 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. 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: true 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. - `personal_data`: name, date of birth, tax id, country and address - `identity_document`: a government-issued ID - `proof_of_address`: an address document; appears only when the identity document carried no address - `occupation`: job title and occupation category - `tax_document`: a region-specific tax document. In Mexico, the Constancia de Situación Fiscal - `email_confirmation`: the customer confirming the email you registered - `selfie`: a live face capture; cannot be uploaded - `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 - tax_document - 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, by being launched into the hosted step: confirming their own email, sitting for the liveness capture, and accepting the agreement. 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. 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. ````