Create RFQ

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.