> ## 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 a verification questionnaire > Submit the customer's answers to one questionnaire, named by `type`. | `type` | Answers | Applies to | |---|---|---| | `occupation` | `jobTitle`, `industry` | Every customer | | `agreement` | `acceptTerms`, `signatureName`, `signatureDate` | Customers who accepted under your terms | Documents are uploaded through [`POST /ramp/customer/{customer_id}/verification/documents`](/api-reference/kyc/upload-verification-documents). **`agreement` is a legal declaration, affirmed by `acceptTerms: true`.** By default the customer accepts the agreement themselves in `/idv`. Send `agreement` only if your own terms incorporate ours and you already collected their acceptance. [The customer agreement](/guides/kyc-api#the-customer-agreement) sets out what you are declaring. **Submit the customer's personal data first**, or this answers `409`. As with document upload, the stage that asks these questions doesn't exist on the customer until then. **Send `agreement` only once `customer_agreement` is in the requirements list.** It belongs to the last stage, after the identity stage and any proof of address, so do not send it together with `occupation`. An early `agreement` answers `202`, then is refused in the background, and a `kyc_updated` webhook arrives with `needsWork: true`. See [Requirements unlock in stages](/guides/onboarding#requirements-unlock-in-stages). **Answers `202`, not `200`.** `industry` is resolved against the live category list in the background, so an unrecognized value doesn't fail the request: it leaves the occupation requirement outstanding. ## OpenAPI ````yaml /openapi.json post /ramp/customer/{customer_id}/verification/questionnaire 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/questionnaire: post: tags: - KYC summary: Submit a verification questionnaire description: >- Submit the customer's answers to one questionnaire, named by `type`. | `type` | Answers | Applies to | |---|---|---| | `occupation` | `jobTitle`, `industry` | Every customer | | `agreement` | `acceptTerms`, `signatureName`, `signatureDate` | Customers who accepted under your terms | Documents are uploaded through [`POST /ramp/customer/{customer_id}/verification/documents`](/api-reference/kyc/upload-verification-documents). **`agreement` is a legal declaration, affirmed by `acceptTerms: true`.** By default the customer accepts the agreement themselves in `/idv`. Send `agreement` only if your own terms incorporate ours and you already collected their acceptance. [The customer agreement](/guides/kyc-api#the-customer-agreement) sets out what you are declaring. **Submit the customer's personal data first**, or this answers `409`. As with document upload, the stage that asks these questions doesn't exist on the customer until then. **Send `agreement` only once `customer_agreement` is in the requirements list.** It belongs to the last stage, after the identity stage and any proof of address, so do not send it together with `occupation`. An early `agreement` answers `202`, then is refused in the background, and a `kyc_updated` webhook arrives with `needsWork: true`. See [Requirements unlock in stages](/guides/onboarding#requirements-unlock-in-stages). **Answers `202`, not `200`.** `industry` is resolved against the live category list in the background, so an unrecognized value doesn't fail the request: it leaves the occupation requirement outstanding. operationId: submit_verification_questionnaire 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: oneOf: - title: occupation type: object additionalProperties: false required: - type - jobTitle - industry properties: type: type: string description: >- Which questionnaire these answers are for. New values may be added. If this names a questionnaire that does not exist, the request is rejected and the error tells you which names are valid. enum: - occupation example: occupation jobTitle: type: string description: >- The customer's occupation, free text. Up to 255 characters. example: Software Engineer industry: type: string description: >- Occupation category: a `code` from [GET /ramp/verification/occupations](/api-reference/kyc/list-occupation-categories). The `label` is not accepted; it is display copy and can be reworded. example: '4430200' - title: agreement type: object additionalProperties: false required: - type - acceptTerms - signatureName - signatureDate properties: type: type: string description: >- Which questionnaire these answers are for. New values may be added. If this names a questionnaire that does not exist, the request is rejected and the error tells you which names are valid. enum: - agreement example: agreement acceptTerms: type: boolean enum: - true description: >- Your affirmation of [the declaration](/guides/kyc-api#the-customer-agreement). Must be `true`. example: true signatureName: type: string maxLength: 255 description: >- The name the customer typed to sign, in their own words. Printed on their agreement in a cursive face, so it appears as the signature on the executed document. example: Ana Ejemplo signatureDate: type: string format: date description: >- When the customer accepted, `YYYY-MM-DD`. Printed on their agreement as the date of signature. Should be within one day of today's date. example: '2026-08-24' 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: a missing or unrecognized `type`; a blank `jobTitle` or `industry`; an `acceptTerms` that is not `true`; a `signatureName` that is blank or over 255 characters; or a `signatureDate` that is not `YYYY-MM-DD` or is not within a day of today. Also returned when the customer is a business account. content: text/plain: schema: type: string example: signatureName is required '404': description: >- No organization exists with that `customer_id`, or it is not a customer of your organization. '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; the `kyc_updated` webhook fires when routing completes, and a retry after it succeeds; or their verification is already approved or denied and cannot be modified. 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. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.