OKX Convert: What the Ten-Second Quote Actually Commits To

Convert is a quote, and a quote has a clock

The first thing to unlearn about OKX Convert is the order-book mental model. There is no bid, no ask and no queue. A user asks for a rate, OKX returns one with an identifier and a validity period, and the conversion either executes against that quote or does not happen.

The help centre states the user-facing version: the conversion rate is updated every ten seconds, and if the user does not confirm within ten seconds, the page must be refreshed to receive a new rate. The API states the same rule in a form a program can use: estimate-quote returns quoteTime and ttlMs, where ttlMs is the validity period of the quotation in milliseconds. The documented example is 10000.

That difference matters. A client that hard-codes ten seconds is guessing; a client that computes quoteTime + ttlMs is reading the contract the venue actually published. If OKX changes the window, the hard-coded client silently sends trades against quotes it believes are live.

The two calls, and what sits between them

The Convert API is deliberately small.

POST /api/v5/asset/convert/estimate-quote takes baseCcy, quoteCcy, side, rfqSz and rfqSzCcy, plus optional clQReqId, tag and convertMode. It returns a quoteId, the quotation time, the time to live, the convert price cnvtPx, and the base and quote amounts. The side is defined relative to the base currency: buy or sell.

POST /api/v5/asset/convert/trade takes the quoteId, the same currency pair and side, the size and its currency, and optional client identifiers. OKX’s documentation is explicit that an estimate quote should be made before a convert trade, and that only assets in the trading account are supported.

There is no third call to cancel. A quote that is not executed expires; it does not rest on a book and it does not need to be withdrawn. That is the convenience of the product and the source of most of its surprises.

Price, spread and the number the user remembers

Convert does not publish a fee line. It publishes a price, and the help centre describes what that price contains: the amount received is based on the quote available when the conversion is confirmed, and the result may reflect the quoted conversion price, an applicable spread and current market conditions.

That wording is worth taking literally. The quote is the price the venue is willing to transact at, and the spread is inside it rather than added on top. A user comparing Convert with a spot order should compare the effective rate — quote amount received divided by amount sent — rather than looking for a fee field that does not exist. The order details show the confirmed quote and the amount actually received; the Portfolio page shows a current estimated value at the latest market price, which is a different number and not evidence of a bad fill.

The help article also answers the question that follows a cancelled or expired quote: the next quote will not be the same, because Convert uses real-time quotes. Cancelling, restarting or letting a quote expire all lead to a new rate. There is no price protection across the gap.

What the API guarantees, and what it does not

The response to a successful convert trade is a single record with state equal to fullyFilled, plus fillPx, fillBaseSz, fillQuoteSz, tradeId and quoteId. The documented failure state is rejected.

That is a narrower contract than an order book provides, and it is useful precisely because it is narrow:

• No partial fills. The response describes one executed conversion, not a series of matches. A client does not need to aggregate fills or track a remaining quantity.
• No resting state. There is no open Convert order to query later. Either the trade call succeeded or it did not.
• No price improvement to model. fillPx is the price of the quote that was executed. A client that wants to measure slippage has to compare cnvtPx from the estimate with fillPx from the trade, and the difference is the quote changing between calls, not the book moving within a fill.

The clQReqId and clTReqId fields are the client-side identifiers for the quote request and the trade request. They are optional, and they are the only practical way to reconcile a retry: a network timeout on the trade call leaves the client unsure whether the conversion happened, and the client order id is what makes the history lookup unambiguous.

Rate limits are part of the quote design

The documented limits are specific enough to shape a client:

• estimate-quote: 10 requests per second per user, and 1 request per 5 seconds per instrument.
• convert trade: 10 requests per second per user, and 1 request per 5 seconds for the same side.

The per-instrument and per-side limits are the ones that bind. A strategy that wants to re-quote every second on one pair cannot: the instrument-level limit permits one quote every five seconds. That is consistent with a ten-second quote life — the venue is not designed for high-frequency re-quoting, and a client that treats Convert as a low-latency execution venue is using the wrong product.

For a slower workflow — a treasury conversion, a fee top-up, a position funded from a different asset — the limits are irrelevant and the quote model is an advantage, because the price is known before the trade is sent.

Reconciling a conversion

The Convert history endpoint, GET /api/v5/asset/convert/history, is the record of what happened. A reconciliation that works looks like this:

1. Store quoteId, quoteTime, ttlMs and cnvtPx when the estimate returns.
2. Send the trade with a clTReqId that is unique and traceable.
3. On a timeout, query the history by the client order id before retrying. A retry with a fresh quote is a second conversion, not a repeat of the first.
4. Compare fillQuoteSz with the amount that left the trading account, and fillBaseSz with the amount that arrived. The difference between cnvtPx * fillBaseSz and fillQuoteSz is the rounding and the spread, not a missing fee.
5. If the state is rejected, do not assume the balance is unchanged until the history confirms it.

The account-routing step is the other half of reconciliation. Convert draws on the Trading account, so a transfer from Funding is a separate ledger event with its own timestamp. Our guide to where an OKX balance sits covers that split; a conversion that appears to have used the wrong balance is usually a transfer that had not settled into the trading account yet.

Where Convert fits, and where it does not

Convert is a good fit when the goal is to change one asset into another at a known price and the timing is not competitive: paying a fee balance, rotating a treasury, consolidating a position. It is a poor fit when the goal is to capture a spread, because the spread is the venue’s, and when the goal is to execute a large order with minimal market impact, because there is no book to walk and the quote is the whole liquidity.

The distinction is the same one that separates a quote from an order in any market. An order book tells you what other participants are willing to do; a quote tells you what one participant is willing to do for a stated number of milliseconds. Reading Convert as the first when it is the second is how a ten-second window becomes an unexpected fill.

For the cost that sits inside the quoted rate, see OKX trading fees. For why a quoted price and an executed price can diverge even without a book, see spread, depth and slippage. And for the contract-size arithmetic that matters when a conversion is funding a derivatives position rather than a spot balance, see one OKX contract is not one coin.

Risk note. The quote lifetime, request parameters, response states, rate limits and user-facing behaviour in this article were read from OKX’s API documentation and help centre on 2026-11-02. Quote windows and limits can change; the difference between a quote and a resting order does not. Nothing here is investment advice.