> ## 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. # Submit verification data > First call in the [KYC API](/guides/kyc-api) flow. Nothing else is accepted before it: `country` is what routes the customer to their country's requirements. **Answers `202`, not `200`.** The request is validated before we answer; recording it upstream happens after. A `202` means accepted, not satisfied. Read the result from the `kyc_updated` webhook or [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status). Re-submitting overwrites what was sent before, and never moves the customer's review status on its own. Personal accounts only. ## OpenAPI ````yaml /openapi.json post /ramp/customer/{customer_id}/verification 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: post: tags: - KYC summary: Submit verification data description: >- First call in the [KYC API](/guides/kyc-api) flow. Nothing else is accepted before it: `country` is what routes the customer to their country's requirements. **Answers `202`, not `200`.** The request is validated before we answer; recording it upstream happens after. A `202` means accepted, not satisfied. Read the result from the `kyc_updated` webhook or [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status). Re-submitting overwrites what was sent before, and never moves the customer's review status on its own. Personal accounts only. operationId: submit_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/SubmitVerificationRequest' responses: '202': description: >- Accepted and being applied. The customer's current verification status is returned. content: application/json: schema: $ref: '#/components/schemas/VerificationStatusResponse' '400': description: >- Validation failed. The plain text body lists every missing or invalid field at once, including a `country` that is not ISO 3166-1 alpha-3. Also returned when the customer is a business account, which verifies through [KYB](/guides/kyb), and when the `customer_id` exists but is not a child of your organization. content: text/plain: schema: type: string example: >- dateOfBirth must be a date in YYYY-MM-DD format; country 'MX' is not a recognized ISO 3166-1 alpha-3 country code (e.g. MEX); address.city is required '404': description: No organization exists with that `customer_id`. '409': description: >- This customer's verification is already approved or denied and cannot be modified. A denied customer resubmits by being launched into the hosted step, not over the API. content: text/plain: schema: type: string example: >- This customer's verification is already approved; it cannot be modified components: schemas: SubmitVerificationRequest: type: object description: Personal data a partner submits on the customer's behalf. required: - firstName - lastName - dateOfBirth - taxId - country - address properties: firstName: type: string lastName: type: string dateOfBirth: type: string description: '`YYYY-MM-DD`. Any other format is a 400.' example: '1990-01-01' taxId: type: string description: >- The customer's tax identification number. The RFC for a Mexican customer. example: XAXX010101000 country: type: string description: >- The customer's country, as an ISO 3166-1 alpha-3 code. Alpha-2 codes and country names are rejected. This is the one country field for the customer (there is no separate nationality), and its value routes them to their country's requirements. example: MEX address: $ref: '#/components/schemas/VerificationAddress' example: firstName: Ana lastName: Ejemplo dateOfBirth: '1990-01-01' taxId: XAXX010101000 country: MEX address: street: Av. Reforma 100 city: Ciudad de Mexico region: CDMX postalCode: '06600' country: MEX VerificationStatusResponse: type: object description: >- Where the customer's verification stands after a partner write. `status` is the same value `GET /ramp/customer/{customer_id}/kyc` reports, so there is one vocabulary across both. required: - customerId - status properties: customerId: type: string format: uuid status: type: string description: >- The customer's overall verification status. A write never moves it on its own. enum: - not_started - in_progress - submitted - approved - denied example: customerId: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: in_progress VerificationAddress: type: object description: >- The customer's residential address. Required, and it must match the identity document you upload; the provider cross-checks the two. required: - street - city - country properties: street: type: string example: Av. Reforma 100 city: type: string example: Ciudad de Mexico region: type: - string - 'null' description: State or province. example: CDMX postalCode: type: - string - 'null' description: >- Optional, because some countries issue none. Send it when the country has one. example: '06600' country: type: string description: ISO 3166-1 alpha-3. example: MEX buildingNumber: type: - string - 'null' flatNumber: type: - string - 'null' securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: API key sent in the Authorization header. ````