> ## 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 order approval > Submits the owner's approval for an embedded-wallet order transaction. Sign the `approvalMessage` from the order's `approval` with the owner's P-256 key and submit the signature as a **hex string** (Turnkey stamp envelopes are not accepted). One signature per call; an M-of-N quorum is a separate call per signer. The `approvalMessage` MUST be byte-identical to what was signed and the `approvalMessageId` MUST match the order's current approval, or the call is rejected as stale. Server-side signers typically output ~142-character DER-wrapped hex; browser WebCrypto outputs 128-character raw `r‖s` hex. Either layout is accepted. Invalid hex, wrong length, or a signature that does not verify over `approvalMessage` is rejected synchronously with `400`. ## OpenAPI ````yaml /openapi.json post /ramp/order/{order_id}/approvals 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: Onboarding description: Hosted and programmatic customer onboarding. - 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 and check customer KYC status. - name: Webhooks description: Event notification subscriptions. - name: Organizations description: Organization identity, child orgs, and partner fees. paths: /ramp/order/{order_id}/approvals: post: tags: - Orders summary: Submit order approval description: >- Submits the owner's approval for an embedded-wallet order transaction. Sign the `approvalMessage` from the order's `approval` with the owner's P-256 key and submit the signature as a **hex string** (Turnkey stamp envelopes are not accepted). One signature per call; an M-of-N quorum is a separate call per signer. The `approvalMessage` MUST be byte-identical to what was signed and the `approvalMessageId` MUST match the order's current approval, or the call is rejected as stale. Server-side signers typically output ~142-character DER-wrapped hex; browser WebCrypto outputs 128-character raw `r‖s` hex. Either layout is accepted. Invalid hex, wrong length, or a signature that does not verify over `approvalMessage` is rejected synchronously with `400`. operationId: submit_order_approval parameters: - name: order_id in: path description: The order ID required: true schema: type: string format: uuid requestBody: content: application/json: schema: type: object required: - approvalMessageId - approvalMessage - signature properties: approvalMessageId: type: string format: uuid description: >- The `approvalMessageId` from the order's `approval`. Echoed back to guard against approving a superseded proposal: a stale id is rejected and the caller re-reads the order for the current one. approvalMessage: type: string description: >- The exact `approvalMessage` bytes the owner signed, byte-identical to what was signed. Validated against the pending proposal. signature: type: string description: >- ECDSA P-256 signature over the `approvalMessage`, as a hex string. Most server-side signers output DER-wrapped hex (~142 characters, often starts with `30`); browser WebCrypto outputs raw `r‖s` as 128 hex characters. Either layout is accepted. See the worked example in [Embedded Wallets](/guides/embedded-wallets#sign-the-approval). publicKey: type: string description: >- Optional compressed SEC1 signer public key. When omitted, the wallet's registered `signerPublicKey` is used. When provided, it must match. required: true responses: '200': description: Approval accepted content: application/json: schema: type: object required: - approvalMessageId - completed properties: approvalMessageId: type: string format: uuid description: Echoed from the request. completed: type: boolean description: >- Whether the embedded-wallet transaction is now fully approved. Embedded wallets use a single owner key today, so a successful `200` always returns `true`. '400': description: >- Invalid signature format or length, signature does not verify over approvalMessage, publicKey mismatch, or approvalMessage does not match the pending proposal '404': description: Order not found or not visible to your API key '409': description: >- The order is dead (canceled/refunded, nothing to approve), or the `approvalMessageId` is stale; re-read the order for the current approval '410': description: >- The proposal expired and was retired; a replacement is minted and surfaces on the order like any refresh components: securitySchemes: ApiKeyAuth: type: apiKey in: header name: Authorization description: API key sent in the Authorization header. ````