--- title: "Create RFQ" method: POST path: "/rfqs" tags: ["Rfqs"] --- # Create RFQ `POST /rfqs` Creates an RFQ for the authenticated account. RFQ creation is asynchronous. Subscribe to the private WebSocket channel `rfq` before sending the request. A successful HTTP response is `202 Accepted` and contains a Paradex `request_id`; it confirms only that the command was queued. The later WebSocket `RESULT` event with the same `request_id` reports whether the venue accepted the command. On success, the event's top-level `rfq_id` is the venue-issued identifier used by the read, execute, cancel, and filtered-subscription APIs. The request accepts up to 25 legs. It must contain at least one strategy leg, represented by omitting `price`. At least one strategy leg must have `side=BUY`, and at least one must have `ratio=1`. A fixed-price hedge leg includes a strictly positive `price`. All quantities and ratios are positive decimal strings. Every leg market must exist on Paradex and be available for RFQ. Each fixed hedge price must be an exact multiple of that market's minimum price increment. The strategy quantity must be at least the largest minimum block size among its strategy legs. The optional `side` commits the RFQ to one direction of the strategy, `BUY` or `SELL`, read the same way as a leg's `side`. Omitting it leaves the RFQ two-way. Makers always quote both directions either way; what the commitment changes is the taker's own side. A committed RFQ may only be executed in that direction, an execute on the other one is rejected, and the collateral held against it covers that direction alone instead of the more expensive of the two. So committing is cheaper for a taker who already knows which way they are going. An account may hold only one two-way RFQ open at a time, and any number of committed ones up to a total limit. An RFQ stays open until the venue closes it. Cancelling is what closes it, but the cancellation is asynchronous: an account is normally free to create its next two-way RFQ once the WebSocket `RESULT` event for the cancel reports success, not when the cancel request is sent. A create issued before that, or immediately after it, may be rejected by a `RESULT` event saying the account already has an RFQ open, and can be retried. The platform selects eligible counterparties; a client-supplied `counterparties` value is ignored. The optional `strategy` field is a draft label and is not sent to the venue. The optional `max_slippage` bounds how far this RFQ may execute from mark, as a fraction of the underlying's spot price, for this RFQ only. It replaces the configured bound, must be greater than zero and at most 1, and applies to every underlying the strategy touches. It sets both the collateral held against the RFQ and the limit the venue enforces on quotes, so a wider value holds more collateral and accepts a worse execution. The market's own price band still applies, so a value beyond it changes neither. Validation or risk-check failures that occur after queueing are reported by the WebSocket `RESULT` event. Its `result.allowed_side` is the direction the RFQ was accepted for: the committed `side` when the request carried one, `TWO_WAY` when it did not, and `BUY` or `SELL` when a two-way request was accepted for one direction only because the account cannot sustain the other. `result.allowed_side` is what the commitment and the reserve above are stated in, so it, and not the `side` that was sent, is the answer to read. Where Paradex does not risk-check the create it is empty, and a `side` sent with that request commits nothing: the RFQ is two-way, and either direction may be executed. ## Request body - RequestsRfqCreateRequest - `counterparties` string[] — Reserved for future use; currently ignored for RFQ creation and drafts - `is_anonymous` boolean — Whether to hide the taker desk name from RFQ counterparties; ignored for drafts - `label` string — User-defined RFQ label; ignored for drafts - `legs` RequestsRfqLeg[], required — Strategy and optional fixed-price hedge legs; maximum 25 - `market` string, required — Paradex market symbol - `price` string — Positive fixed price in the instrument's quote currency; set only for hedge legs - `ratio` string, required — Positive decimal multiplier for the leg - `side` 'BUY' | 'SELL', required — Leg direction - `max_slippage` string — MaxSlippage bounds how far this RFQ may execute from mark, as a fraction of underlying spot, replacing the configured bound for this RFQ only. Empty leaves the configured one in place. Ignored for drafts. - `quantity` string, required — Positive total strategy size - `side` 'BUY' | 'SELL' — Side commits the RFQ to one direction of the strategy, which is then the only direction it may be executed in. Empty leaves it two-way. Ignored for drafts. - `strategy` string — Draft strategy label; maximum 64 bytes and defaults to custom for drafts; ignored on RFQ create ## Response `202` Accepted - ResponsesRfqAcceptedResponse - `accepted_at` integer — Unix milliseconds when the request was queued - `request_id` string — request_id identifies this request. It is echoed on the RESULT event delivered later on the WebSocket rfq channel, so a client with several requests in flight can match each outcome to the request that caused it. On Create it is the only identifier available until the venue issues the rfq_id. ## Other responses - `400` — Bad Request - `401` — Unauthorized - `403` — Forbidden ## Changes - **2026-08-30** `6e7678554538` — 1 info - added the new optional request property `side` - **2026-08-14** `fbf863c1822f` — 1 info - added the new optional request property `max_slippage` - **2026-08-12** `0574c98df104` — 1 info - endpoint added [Change history](https://skmtc.dev/tradeparadex/apis/paradex-rest-api-2/changes/rfqs/post.md) --- [API](https://skmtc.dev/tradeparadex/apis/paradex-rest-api-2.md) · [All operations](https://skmtc.dev/tradeparadex/apis/paradex-rest-api-2/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/tradeparadex/paradex-rest-api-2/revisions/a73698fdee53/schema)