> ## 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. # Upload verification documents > Upload the customer's documents as `multipart/form-data`. Send at least one of `id_front`, `id_back`, `proof_of_address` or `tax_document`. **Submit the customer's personal data first.** Until [`POST /ramp/customer/{customer_id}/verification`](/api-reference/kyc/submit-verification-data) has run the customer has no stages to upload against, so this answers `409`. **Answers `202`, not `200`.** Every part is read and checked before we answer; the upload itself is upstream work the caller shouldn't wait on. Watch [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status) for the requirement to go satisfied. ## OpenAPI ````yaml /openapi.json post /ramp/customer/{customer_id}/verification/documents 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/documents: post: tags: - KYC summary: Upload verification documents description: >- Upload the customer's documents as `multipart/form-data`. Send at least one of `id_front`, `id_back`, `proof_of_address` or `tax_document`. **Submit the customer's personal data first.** Until [`POST /ramp/customer/{customer_id}/verification`](/api-reference/kyc/submit-verification-data) has run the customer has no stages to upload against, so this answers `409`. **Answers `202`, not `200`.** Every part is read and checked before we answer; the upload itself is upstream work the caller shouldn't wait on. Watch [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](/api-reference/kyc/get-kyc-status) for the requirement to go satisfied. operationId: upload_verification_documents 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: multipart/form-data: schema: type: object properties: id_front: type: string format: binary description: >- Front of the identity document, or its only side. JPEG, PNG or PDF, up to 10 MB. At least one of `id_front`, `id_back`, `proof_of_address` or `tax_document` must be sent. id_back: type: string format: binary description: >- Back of the identity document, where it has two sides. JPEG, PNG or PDF, up to 10 MB. Required whenever `id_type` is `id_card` or `drivers_license`, and refused for `passport`, which is single-sided. Both sides go in the same request: sending this without `id_front` is a 400, so a back cannot be added to an earlier upload on its own. id_type: type: string description: >- Which identity document the `id_*` parts are. Required whenever one is sent. Case-sensitive: send the value exactly as listed. enum: - ID_CARD - PASSPORT - DRIVERS proof_of_address: type: string format: binary description: >- A document evidencing the customer's address. JPEG, PNG or PDF, up to 10 MB. Only accepted once the proof-of-address requirement is outstanding: sent earlier it is accepted with a 202 and then dropped, leaving the requirement outstanding. proof_of_address_type: type: string description: >- Which kind of address document it is. Case-sensitive: send the value exactly as listed. default: UTILITY_BILL enum: - UTILITY_BILL - BANK_STATEMENT - TAX_BILL - EMPLOYMENT_CERTIFICATE - PROPERTY_DEED - INVOICE tax_document: type: string format: binary description: >- A tax document, where the customer's country requires one; in Mexico, the Constancia de Situación Fiscal. JPEG, PNG or PDF, up to 10 MB. Not recorded for a customer whose verification does not collect one. See [Country-specific requirements](/guides/onboarding#country-specific-requirements). country: type: string description: >- Issuing country of these documents, as an ISO 3166-1 alpha-3 code. Only needed when the customer's profile has no country yet. example: MEX encoding: id_front: contentType: image/jpeg, image/png, application/pdf id_back: contentType: image/jpeg, image/png, application/pdf proof_of_address: contentType: image/jpeg, image/png, application/pdf tax_document: contentType: image/jpeg, image/png, application/pdf 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. An unrecognized `id_type` or `proof_of_address_type` is refused with the valid values listed. Otherwise the plain text body names the first problem: a two-sided `id_type` without `id_back`, `id_back` without `id_front`, `id_back` for a single-sided `id_type`, a missing `id_type` alongside an `id_*` part, an unsupported content type, an empty or oversized file, an unrecognized `country`. Also returned when the customer is a business account, and when the `customer_id` exists but is not a child of your organization. content: text/plain: schema: type: string example: >- id_back is required for ID_CARD, which is two-sided; send both sides in the same request '404': description: No organization exists with that `customer_id`. '409': description: >- Not now, rather than never: all three cases are retryable or resolvable. Either nothing has been submitted for this customer yet, so submit their personal data first; or their personal data landed but the customer has not been routed to their country's requirements yet, so the stage this would attach to does not exist, and the `kyc_updated` webhook fires when routing completes (without a webhook, watch `GET /ramp/customer/{customer_id}/kyc?requirements=true` for the requirements list to appear); or their verification is already approved or denied and cannot be modified. content: text/plain: schema: type: string example: >- Submit this customer's personal data first (POST /ramp/customer/{customer_id}/verification). Documents and questionnaire answers are accepted once that is done. components: schemas: 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 securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: API key sent in the Authorization header. ````