> ## 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](/v2/guides/kyc-sumsub-shared-token). Answers **`200`**, not `202`: the import is committed before the response, which carries the same requirements breakdown as [`GET /organization/{organizationId}/kyc?requirements=true`](/v2/api-reference/kyc/get-kyc-status). That breakdown covers the identity stage only. Send what it lists, then wait for `kycUpdated` and read the requirements again: `proofOfAddress` and `customerAgreement` appear only when the customer reaches their stages. See [Requirements unlock in stages](/v2/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. ## OpenAPI ````yaml openapi-v2.json POST /organization/{organizationId}/verification/import openapi: 3.1.0 info: title: Etherfuse FX API description: >- Partner-facing ramp API, version 2: payment accounts, quotes, orders and webhooks. license: name: Proprietary version: 2.0.0 servers: - url: https://api.sand.etherfuse.com description: Sandbox security: - ApiKeyAuth: [] tags: - name: Payment Accounts description: >- Register the bank accounts and wallets that money moves from and to, and read their readiness per rail. - name: Quotes description: Price a transfer between two registered payment accounts. - name: Orders description: Create orders from quotes and track them. - name: Webhook Subscriptions description: Subscribe to webhook events. - name: Webhook Events description: Payloads Etherfuse sends to your webhook subscriptions. - name: Sandbox description: Endpoints that work only in sandbox, for testing. - name: Assets description: The markets and tokens a quote can use, and the balances of a wallet. - name: Authentication description: >- Partner JWT authentication: exchange a JWT for an access token, or launch a user into the app. - 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: KYB description: Check where a business organization's KYB stands. - name: Lookup description: >- Public reference data: exchange rates, stablebonds, bond costs, country codes. - name: Organizations description: >- Your organization, your default partner fee, and the customer organizations you create. - name: Members description: >- The people who belong to a customer business organization and complete its KYB. - name: Statements description: >- Monthly revenue share statements for closed months, as a list or as a CSV or PDF download. paths: /organization/{organizationId}/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](/v2/guides/kyc-sumsub-shared-token). Answers **`200`**, not `202`: the import is committed before the response, which carries the same requirements breakdown as [`GET /organization/{organizationId}/kyc?requirements=true`](/v2/api-reference/kyc/get-kyc-status). That breakdown covers the identity stage only. Send what it lists, then wait for `kycUpdated` and read the requirements again: `proofOfAddress` and `customerAgreement` appear only when the customer reaches their stages. See [Requirements unlock in stages](/v2/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. operationId: v2ImportVerification parameters: - $ref: '#/components/parameters/OrganizationId' 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: >- `invalid-request`; `detail` says why. Any of: `shareToken` missing; 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 organization is a business. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' '401': $ref: '#/components/responses/Unauthorized' '404': $ref: '#/components/responses/OrganizationNotFound' '409': description: >- `conflict`: this customer's verification has already started. A session can only be imported before verification begins. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' '500': $ref: '#/components/responses/InternalError' components: parameters: OrganizationId: name: organizationId in: path required: true description: >- The organization this call acts for: your API key's organization or one of its customer organizations. Any other id returns `404` `not-found`. schema: type: string format: uuid 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 field is 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... ImportVerificationResponse: type: object description: The outcome of importing a verification session. required: - organizationId - status - requirements properties: organizationId: type: string format: uuid status: $ref: '#/components/schemas/VerificationStatus' requirements: type: array description: >- What is still outstanding after the import: the same breakdown `GET /organization/{organizationId}/kyc?requirements=true` returns. items: $ref: '#/components/schemas/RequirementState' example: organizationId: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: inProgress requirements: - type: personalData status: satisfied requiresLaunch: false - type: identityDocument status: satisfied requiresLaunch: false - type: occupation status: pending requiresLaunch: false - type: selfie status: satisfied requiresLaunch: true - type: customerAgreement status: pending requiresLaunch: false Problem: type: object description: >- RFC 9457 problem details. Every v2 error uses this body with content type `application/problem+json`. `errors` is present only on `validation-error`. `required` and `missing` are present only on `registration-info-required`. required: - type - title - status - detail - instance properties: type: type: string format: uri description: >- `https://docs.etherfuse.com/ramp/v2/errors/` followed by the problem slug, for example `https://docs.etherfuse.com/ramp/v2/errors/quote-expired`. Switch on this value. example: https://docs.etherfuse.com/ramp/v2/errors/quote-expired title: type: string description: Short summary of the problem type. example: Quote expired status: type: integer description: The HTTP status code. example: 400 detail: type: string description: Human-readable explanation of this occurrence. Do not parse it. example: >- quote 5e6f7a8b-9c0d-4e1f-8a2b-3c4d5e6f7a8b has expired or does not exist instance: type: string description: Unique identifier for this occurrence. Quote it to support. example: >- tag:etherfuse.com,2026-08-28:R2-10120/0b1c2d3e-4f50-4a6b-8c7d-9e0f1a2b3c4d errors: type: array description: Present on `validation-error`. One entry per invalid field. items: $ref: '#/components/schemas/FieldViolation' required: type: array description: >- Present on `registration-info-required`. Every registration field the route requires, as JSON Pointers into the request, for example `#/registrationInfo/taxId`. items: type: string missing: type: array description: >- Present on `registration-info-required`. The required fields you must still send, as JSON Pointers into the request. items: type: string VerificationStatus: type: string enum: - notStarted - inProgress - submitted - approved - denied description: |- - `notStarted`: verification has not started. - `inProgress`: the customer started but has not submitted everything. - `submitted`: submitted and waiting for review. - `approved`: cleared. - `denied`: rejected, or a previous approval was revoked. 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. - `personalData`: name, date of birth, tax id, country and address - `identityDocument`: a government-issued ID - `proofOfAddress`: an address document; appears only when the identity document carried no address - `occupation`: job title and occupation category - `taxDocument`: a region-specific tax document. In Mexico, the Constancia de Situación Fiscal - `emailConfirmation`: the customer confirming their email address - `selfie`: a live face capture; cannot be uploaded - `customerAgreement`: the customer accepting the required agreements We may add requirements, and will update these docs when we do. A country may also introduce one of its own; see [Country-specific requirements](/v2/guides/onboarding#country-specific-requirements). enum: - personalData - identityDocument - proofOfAddress - occupation - taxDocument - emailConfirmation - selfie - customerAgreement 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 - `awaitingReview`: provided, not yet reviewed - `actionRequired`: **reviewed and rejected**, so it must be provided again, corrected Tell `pending` and `awaitingReview` apart: a shared verification whose identity document and selfie transferred reads `awaitingReview` for both, so do not read `pending` into it and send them again. More values may be added, so act on the two that carry an instruction (`satisfied` means done, `actionRequired` means send again) and treat anything else as in progress. enum: - satisfied - pending - awaitingReview - actionRequired 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: identityDocument status: pending requiresLaunch: false FieldViolation: type: object required: - pointer - detail properties: pointer: type: string description: >- JSON Pointer to the field in the request, for example `#/accountDetails/clabe`. example: '#/accountDetails/clabe' detail: type: string description: What is wrong with the field. example: This field is required. responses: Unauthorized: description: >- `unauthorized`: the `Authorization` header is missing, not ASCII, or does not hold a valid API key. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' OrganizationNotFound: description: '`not-found`: your API key cannot act for this organization.' content: application/problem+json: schema: $ref: '#/components/schemas/Problem' InternalError: description: >- `internal-error`: an unexpected error on our side. Retry with backoff, and quote `instance` to support if it persists. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: API key sent in the Authorization header, with no `Bearer` prefix. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.