> ## Documentation Index > Fetch the complete documentation index at: https://docs.houdiniswap.com/llms.txt > Use this file to discover all available pages before exploring further. # Submit signed transaction > Sends the batch on-chain, using the signatures from the user's wallet. - sign the `userOpHash` of each batch from [Build batch transaction](/api-reference/bundler-evm/build-batch-transaction), and send them in the same order - most groups fit in one batch, so usually one signature - fund the smart account first, using `txData` from the build response. For an ERC-20 source `txData.to` is the token contract, not the smart account - 404 means nothing is awaiting submission — either never built, or already submitted. Check [Get batch status](/api-reference/multi-exchange/get-batch-status). ## OpenAPI ````yaml https://api-partner.houdiniswap.com/v2/openapi.json post /exchanges/multi/{multiId}/tx openapi: 3.0.0 info: title: Houdini Swap Partner API version: 2.1.2 description: >- Quote and execute private, standard, and DEX swaps — one at a time or batched. license: name: ISC contact: {} servers: - url: https://api-partner.houdiniswap.com/v2 security: [] tags: - name: Private and Standard Swaps description: >- CEX swaps in two modes, sharing the same endpoints — pick one with the `types` parameter. - `types=standard` — direct single-leg swap. Fastest, no privacy hop. - `types=private` — two legs through a privacy bridge, so deposit and payout are not linkable on-chain. Adds `anonymous`, `useXmr`, `rotatePayoutWallets` and the `inLeg*` / `outLeg*` filters. Flow: [Get tokens](/api-reference/private-and-standard-swaps/get-tokens) with `hasCex=true` → [Get quotes](/api-reference/private-and-standard-swaps/get-quotes) → [Create exchange](/api-reference/private-and-standard-swaps/create-exchange) → [track the order](/api-reference/private-and-standard-swaps/get-order-details). `markup` works in both modes. - name: Private Send description: >- Send a token to another wallet privately — same token in and out, with no on-chain link between the two addresses. - find eligible tokens with [Get tokens](/api-reference/private-send/get-tokens) and `hasSelfPrivate=true` - quote with Get private send quote, then create with Create private send order - you can also stay on the main endpoints with a private same-token `quoteId` See the [Private send](/docs/v2/private-send) guide. - name: Multi-Exchange description: >- Create and track a group of swaps sharing one `multiId`. - post the orders straight to Create multi exchange — there is no quote step and no `quoteId` - Get multi quotes is optional, for showing rates first - each order gets its own deposit address; poll [Get batch status](/api-reference/multi-exchange/get-batch-status) for every leg - CEX standard and private only — no DEX in a batch To fund the whole group in one transaction, see Bundler SOL or Bundler EVM. See the [multi-swap flow](https://docs.houdiniswap.com/developer-hub/swap-flows/multi-swap) for the full sequence. - name: Bundler SOL description: >- Fund a whole multi-exchange group with one Solana batch transfer. - one call — Get batch transaction returns the transaction to sign and broadcast - up to 10 deposits per batch; every order must send the same token - find batchable tokens with [Get tokens](/api-reference/multi-exchange/get-tokens) and `hasBundler=true` - nothing to submit back afterwards — retry and recovery are EVM-only See the [multi-swap flow](https://docs.houdiniswap.com/developer-hub/swap-flows/multi-swap) for the full sequence. - name: Bundler EVM description: >- Fund a whole multi-exchange group with one ERC-4337 UserOperation, submitted through the bundler. - Ethereum, Base and BNB Smart Chain only; other EVM chains are rejected - up to 20 legs per batch; every order must send the same source token - find batchable tokens with [Get tokens](/api-reference/multi-exchange/get-tokens) and `hasBundler=true` - build the UserOp, then submit the signed result - if a bundle fails: retry within 30 minutes, or recover stuck assets See the [multi-swap flow](https://docs.houdiniswap.com/developer-hub/swap-flows/multi-swap) for the full sequence. - name: On-chain DEX or Bridge description: >- On-chain swaps signed and funded from the user's own wallet. Flow: [Get tokens](/api-reference/on-chain-dex-or-bridge/get-tokens) with `hasDex=true` → [Get quotes](/api-reference/on-chain-dex-or-bridge/get-quotes) with `types=dex` → [Get token approval data](/api-reference/on-chain-dex-or-bridge/get-token-approval-data) → send it and poll [Check token allowance](/api-reference/on-chain-dex-or-bridge/check-token-allowance) → [Get next chain signature](/api-reference/on-chain-dex-or-bridge/get-next-chain-signature) → [Create exchange](/api-reference/on-chain-dex-or-bridge/create-exchange) → [Confirm DEX transaction](/api-reference/on-chain-dex-or-bridge/confirm-dex-transaction) → [track the order](/api-reference/on-chain-dex-or-bridge/get-order-details). - `slippage` applies to DEX only - `markup` is not supported - name: Reference Data description: >- Optional lookups: supported chains, liquidity providers, and per-pair min/max swap amounts. Responses are cached and change rarely — safe to fetch once and reuse. Token ids come from `/tokens`, listed in each swap section above. - name: Partner Account description: >- Your orders, profile, earned commissions, withdrawals, volume analytics, and the rate-limit budget attached to your API key. Every endpoint is scoped to the partner that owns the key making the request. - name: System description: >- Service health. [Get system health](/api-reference/system/get-system-health) is unauthenticated and exempt from x402 payment — use it for uptime monitoring. paths: /exchanges/multi/{multiId}/tx: post: tags: - Bundler EVM summary: Submit signed transaction description: >- Sends the batch on-chain, using the signatures from the user's wallet. - sign the `userOpHash` of each batch from [Build batch transaction](/api-reference/bundler-evm/build-batch-transaction), and send them in the same order - most groups fit in one batch, so usually one signature - fund the smart account first, using `txData` from the build response. For an ERC-20 source `txData.to` is the token contract, not the smart account - 404 means nothing is awaiting submission — either never built, or already submitted. Check [Get batch status](/api-reference/multi-exchange/get-batch-status). operationId: SubmitMultiExchangeTx parameters: - description: The multi exchange group ID in: path name: multiId required: true schema: type: string maxLength: 64 example: mx8Qa1 requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/SubmitEvmBatchTxRequest' responses: '200': description: UserOperation(s) submitted content: application/json: schema: $ref: '#/components/schemas/SubmitEvmBatchTxResult' examples: Example 1: value: userOpHashes: - >- 0x9c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f '400': description: Bad request content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: >- Credentials missing, malformed, or rejected — all return `INVALID_API_CREDENTIALS`. Sending only `partner-id` returns `PARTNER_ID_NOT_SUPPORTED`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '402': description: >- Payment required — x402 protocol. The body is empty; what to pay is in the `payment-required` header. Not returned when you send an `Authorization` header. content: application/json: schema: $ref: '#/components/schemas/X402PaymentRequired' headers: payment-required: schema: type: string required: true '403': description: Access Denied content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: No pending transaction found for this multiId content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '422': description: Validation Failed content: application/json: schema: $ref: '#/components/schemas/ValidationError' '429': description: Rate limit exceeded — back off and retry content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - apiKey: [] components: schemas: SubmitEvmBatchTxRequest: properties: signatures: items: type: string type: array description: >- One signature per batch, in the same order as `transactions` in the build response. Sign each batch's `userOpHash` as a message, with the same wallet you passed as `sender` when building. Pass the hash as **bytes**, not as a hex string — signing the `"0x…"` text produces a different digest and the submit is rejected. - viem — `walletClient.signMessage({ account, message: { raw: userOpHash } })` - ethers v6 — `signer.signMessage(getBytes(userOpHash))` - ethers v5 — `signer.signMessage(ethers.utils.arrayify(userOpHash))` minItems: 1 required: - signatures type: object additionalProperties: false SubmitEvmBatchTxResult: properties: userOpHashes: items: type: string type: array description: >- One hash per submitted batch — the on-chain reference for each UserOperation. required: - userOpHashes type: object additionalProperties: false ErrorResponse: properties: message: type: string code: type: string description: >- Machine-readable reason for the failure. Branch on this, not on `message` — messages are free to change. The value depends on the HTTP status. The common ones: - `400` — `BAD_REQUEST` - `401` — `INVALID_API_CREDENTIALS`, `PARTNER_ID_NOT_SUPPORTED` - `403` — `ACCESS_DENIED`, `FIXED_RATE_NOT_ALLOWED` - `404` — `NOT_FOUND`, `TOKEN_NOT_FOUND`, `TOKEN_DISABLED` - `409` — `ALREADY_SUBMITTED`, `STATIC_DEPOSIT_IN_USE` - `422` — `VALIDATION_ERROR`, `AMOUNT_TOO_LOW`, `INVALID_SWAP`, `FIXED_RATE_QUOTE_EXPIRED`, and most other request problems - `429` — `RATE_LIMIT_EXCEEDED` - `5xx` — `INTERNAL_SERVER_ERROR`, `PROVIDER_EXCHANGE_FAILED`, `SERVICE_UNAVAILABLE` New codes are added over time, so treat this as an open set: match the ones you handle and fall back to the HTTP status for the rest. requestId: type: string description: >- Unique id for this request. Quote it when contacting support — it is how we find the failure in our logs. required: - message - code type: object additionalProperties: false X402PaymentRequired: description: >- Body of a `402 Payment required`. Empty — `{}` — for API clients; a request that looks like a browser gets an HTML paywall page instead. This is the x402 payment protocol, not the normal error format, so there is no `code` or `message` to branch on. What to pay is always in the `payment-required` response header, in both cases: base64-encoded JSON whose `accepts[]` entries each carry the `network`, the `asset` to pay in, the `amount`, and the `payTo` address, alongside `maxTimeoutSeconds` and the x402 `scheme`. Sending `Authorization` skips the payment flow, so a 402 only reaches callers paying per request. An `apiKey` query param also skips it but is not a credential — those requests fail with `401 INVALID_API_CREDENTIALS`. properties: {} type: object additionalProperties: false ValidationError: properties: message: type: string code: type: string description: >- Machine-readable reason for the failure. Branch on this, not on `message` — messages are free to change. The value depends on the HTTP status. The common ones: - `400` — `BAD_REQUEST` - `401` — `INVALID_API_CREDENTIALS`, `PARTNER_ID_NOT_SUPPORTED` - `403` — `ACCESS_DENIED`, `FIXED_RATE_NOT_ALLOWED` - `404` — `NOT_FOUND`, `TOKEN_NOT_FOUND`, `TOKEN_DISABLED` - `409` — `ALREADY_SUBMITTED`, `STATIC_DEPOSIT_IN_USE` - `422` — `VALIDATION_ERROR`, `AMOUNT_TOO_LOW`, `INVALID_SWAP`, `FIXED_RATE_QUOTE_EXPIRED`, and most other request problems - `429` — `RATE_LIMIT_EXCEEDED` - `5xx` — `INTERNAL_SERVER_ERROR`, `PROVIDER_EXCHANGE_FAILED`, `SERVICE_UNAVAILABLE` New codes are added over time, so treat this as an open set: match the ones you handle and fall back to the HTTP status for the rest. requestId: type: string description: >- Unique id for this request. Quote it when contacting support — it is how we find the failure in our logs. fields: $ref: '#/components/schemas/FieldErrors' required: - message - code - fields type: object additionalProperties: false FieldErrors: properties: {} type: object additionalProperties: properties: value: {} message: type: string required: - message type: object securitySchemes: apiKey: type: apiKey name: Authorization in: header description: >- Send `Authorization: :` — joined by a colon, raw. No `Bearer` prefix, no base64. [Get your credentials](https://docs.houdiniswap.com/developer-hub/getting-started/authentication) ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.