> ## Documentation Index > Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt > Use this file to discover all available pages before exploring further. # WhiteBIT API Changelog > Track updates, improvements, and fixes to the WhiteBIT API platform including new endpoints and changes. ## TP/SL legs can be modified over WebSocket **`order_modify` accepts TP/SL legs; `collateral_order_tpsl_place` documented as additive** Legs created by `collateral_order_tpsl_place` can be changed with `order_modify` — send the leg's `order_id` or `client_order_id` with a new `activation_price`. Earlier documentation said `order_modify` returned error `160` for a TPSL leg; that statement was incorrect and is removed. Each `collateral_order_tpsl_place` call creates a new pair of TP/SL orders. It does not replace or cancel TP/SL orders already on the position, including those created through the REST API (`takeProfit` / `stopLoss`) or by OTO orders. To change levels, modify the existing orders with `order_modify`, or cancel those orders with `order_cancel` and place new ones. When a TP/SL order triggers and closes the position, the remaining TP/SL orders for that position are cancelled automatically. ## Trading on deposits awaiting confirmation **Deposits become tradable at the first confirmations, and the part still awaiting the network is reported separately** A crypto deposit can now be credited before the network fully confirms it, so the funds are tradable earlier. Until confirmation completes, that part of the balance is held back: it can be moved to the [trade balance](/glossary#balance-spotbalance-trade) and traded, but it cannot be withdrawn, sent as a WhiteBIT Code, or moved to the [collateral balance](/glossary#balance-collateral). [Main balance](/api-reference/account-wallet/main-balance) gains a `pending_deposit_amount` field per currency — the part of `main_balance` that is still held back. It is `0` when nothing is held. A new endpoint, [Withdrawable balance](/api-reference/account-wallet/withdrawable-balance), reports the same picture for the whole account: the total, the held value, and what remains withdrawable, in a stable-coin equivalent, plus a per-currency breakdown of the free amount. Requests that would move held funds off the platform are rejected with code `20` on the `amount` field: [Withdraw](/api-reference/account-wallet/create-withdraw-request), [Withdraw Pay](/api-reference/account-wallet/create-withdraw-request-with-specific-amount), [Express Withdraw](/api-reference/account-wallet/create-express-withdraw-token), and [WhiteBIT Code creation](/api-reference/account-wallet/create-code). [Transfer](/api-reference/account-wallet/transfer-between-balances) to the collateral balance is rejected the same way; transfers to the trade balance are never restricted. Two limits apply at once — the free amount of the currency itself and the free value of the whole account. Whichever is smaller decides, so holding a large balance in other currencies does not make a held currency withdrawable. ## Refund history and memo for deposit refunds **New `POST /api/v4/main-account/refund-history` endpoint and `memo` support for refunds** The Main Account API now returns the account's deposit refunds with the current status of each: `in_process`, `successful`, or `canceled`. The list includes refunds requested through the WhiteBIT interface and through the API. Filter by `depositId` or `ticker`, and page through results with `limit` and `offset`. Only full refunds are listed. `POST /api/v4/main-account/refund-deposit` accepts an optional `memo` for the destination address. The `refund.successful` and `refund.failed` webhooks now include `memo`, which is `null` when no memo was sent. ## RPI and retail flags on the same limit order **`POST /api/v4/order/new` and `POST /api/v4/order/bulk` accept `rpi=true` together with `retail=true`** A limit order may now set both `rpi=true` and `retail=true`; the API no longer rejects the combination with error code `41`, and code `41` is retired. The order rests as an RPI maker and matches exactly like an order with only `rpi=true` — the Retail flag has no effect on it, as on any post-only order. The account still needs both flags enabled: error codes `42` and `43` apply unchanged. ## Account-level maximum leverage on Collateral Trading **`POST /api/v4/collateral-account/leverage` can accept a lower maximum per account** Coming soon: the account-level maximum is not yet enforced by the endpoint. The accepted `leverage` values stay `1`, `2`, `3`, `5`, `10`, `20`, `50` and `100`, but trading restrictions on an account can set a lower maximum. A request above the account's maximum returns HTTP 422 with error code `30` and the message under `errors.leverage`. Leverage already set above the new maximum stays in effect until the next change, so read the current value before assuming a request will be accepted. ## ADL quantile and premium index over WebSocket **Two new push streams for data previously available only by polling** The WebSocket API adds two channels that were already implemented but undocumented: `ADLQuantile_subscribe` (private) pushes the account's ADL deleveraging-priority rank for open futures positions — immediately on subscribe, then every 30 seconds — as an alternative to polling the ADL quantile REST endpoint. `premiumIndex_subscribe` (public) pushes mark price, index price, and funding rate for futures markets every 0.5 seconds, mirroring the data on the futures markets list endpoint. ## Borrow history on Collateral Trading **New `POST /api/v4/collateral-account/borrow-history` endpoint** The Collateral Trading API now returns the borrow history for a collateral account — one record per borrow position, not per underlying engine state change. Each record carries `amount`, `principal`, and `interest` (independently computed peak values — `amount` is not always `principal` + `interest`), plus `status` (`active`, `repaid`, or `liquidated`) and `timestamp`. Filter to one asset with the optional `asset` parameter, and page through results with `startTime`/`endTime`, `limit`, and `offset`. ## Which order fields carry a step, and what a rejection looks like **Per-endpoint `tickSize` and `stepSize` rules ahead of the September 18, 2026 enforcement** The [markets concept page](/concepts/markets#price-and-amount-steps) now lists which request field each step applies to — `price`, `activation_price`, `stop_limit_price` and attached `stopLoss` / `takeProfit` prices against `tickSize`, `amount` against `stepSize` — and every order endpoint states its own rule. An order rejected for a step mismatch returns HTTP 422 with trade error code `1` and the failing field as the key in `errors` — distinct from the endpoints' own validation codes `30`, `32` and `33` — so branch on the code together with the key rather than on the localized message. The amount step does not apply to `POST /api/v4/order/market` and `POST /api/v4/order/stop_market` buy orders, where `amount` is the quote-currency total rather than a quantity. The `activation_price` of a buy stop-market order is still checked. ## Single-call currency conversion **Request and accept a conversion quote in one request** `POST /api/v4/convert/auto-confirm` requests a conversion quote and accepts it in a single call, so the 10-second quote lifetime cannot elapse between requesting a rate and executing at it. The request takes the same `from`, `to`, `direction`, and `amount` fields as [Convert Estimate](/api-reference/convert/convert-estimate), and the response returns `finalGive`, `finalReceive`, and the executed conversion's `id` — usable as the `quoteId` filter on [Convert History](/api-reference/convert/convert-history). An optional `idempotencyKey` of 8 to 128 characters deduplicates retries: the first request claims the key and converts, and a repeat returns the recorded conversion instead of converting again. The claim is short-lived and is never renewed, so review the retry-timing caveat on [Convert Auto Confirm](/api-reference/convert/convert-auto-confirm) before building retry logic. Send a key from any automated caller — without one, a retry converts a second time. The two-step [Convert Estimate](/api-reference/convert/convert-estimate) and [Convert Confirm](/api-reference/convert/convert-confirm) endpoints are unchanged and remain available. The new endpoint is additive. ## Order placement over WebSocket **Place, modify, and cancel orders on the WebSocket connection** From September 2, 2026, the WebSocket API carries order flow alongside market and account streams: 21 JSON-RPC methods place, modify, and cancel spot, margin, and futures orders over the same authorized connection that carries subscriptions. The methods are an alternative transport to the REST order endpoints for latency-sensitive integrations that hold one connection open. Authorize the connection first with the `authorize` frame; an order method on an unauthorized connection is rejected. The transport numbers its errors independently of REST — the same numeric code carries a different meaning on each surface — so branch on the codes documented on the Order Management page rather than reusing REST codes. ## WebSocket rate limits **Per-connection budgets: 10,000 order placements and 12,000 other requests per 10 seconds** The documented WebSocket request limits are updated. Per connection, order placements — the `*_place` methods — are limited to 10,000 requests per 10 seconds, and every other JSON-RPC request (subscriptions, cancellations, modifications, `ping`) counts against a separate budget of 12,000 per 10 seconds. These budgets replace the previously documented cap of 200 requests per minute per connection. The connection limit is unchanged at 1,000 new connections per minute. ## WebSocket host migration **Breaking change: the Global WebSocket host moved to `wss://wss.whitebit.com/ws`** The Global WebSocket endpoint moved from `wss://api.whitebit.com/ws` to `wss://wss.whitebit.com/ws`. Both hosts serve the same channels over the same `/ws` path during a 6-month transition window, after which the legacy host stops accepting connections. Only the host changes. The `/ws` path, the JSON-RPC message format, every market-stream, account-stream, and order-management method name, the `authorize` flow and token format, and the connection and request limits are all unchanged. **Migration guide:** * Replace `wss://api.whitebit.com/ws` with `wss://wss.whitebit.com/ws` in the WebSocket client and redeploy. * Update every hardcoded copy of the host — reconnect helpers, failover lists, client defaults, and environment configuration. A missed copy keeps working until the sunset date and fails then rather than at deploy time. * Subscription logic, message parsing, authorization, and keepalive handling need no change. **Sunset date:** March 1, 2027. **Replacement:** Connect to `wss://wss.whitebit.com/ws`. See [WebSocket API — Host migration](/websocket/overview#host-migration). **Impact:** Every integration on the Global WebSocket host is affected — public market streams, private account streams, and WebSocket order management alike. REST API integrations are not affected; the REST base URL is unchanged. ## Price and quantity steps on Market Info **Breaking change: order price and amount must align to `tickSize` and `stepSize`** `GET /api/v4/public/markets` now returns `tickSize` — the minimal price step a limit order price must be a multiple of — and `stepSize` — the minimal quantity step an order amount must be a multiple of. Both are decimal strings passed through verbatim from the trade engine, so the values follow a precision change on the market automatically. Either field is an empty string when the engine does not provide the value for the market, so handle the empty string before parsing. **Migration guide:** * Read `tickSize` and `stepSize` from `GET /api/v4/public/markets` and validate order price and amount against those two fields, instead of deriving the steps from `moneyPrec`/`stockPrec`. * Handle the empty-string case (the engine does not provide the value for the market) before parsing. **Backward compatibility:** Until September 18, 2026, WhiteBIT maintains backward compatibility for order prices and amounts that are not aligned to `tickSize` and `stepSize`. After September 18, 2026, an order whose price is not a multiple of `tickSize`, or whose amount is not a multiple of `stepSize`, is rejected. **Sunset date:** September 18, 2026. ## Market data, order history, and fee updates This release documents three API updates across market data, order history, and trading fees. ### Mark price on futures markets list **New `mark_price` field on `GET /api/v4/public/futures`** Each futures market entry carries `mark_price` — the fair value of the perpetual contract, derived from the underlying index price and the futures basis. Mark price, not `last_price`, is what a liquidation is evaluated against, so reading it lets an integration reproduce the distance to liquidation the platform itself measures instead of approximating it from the order book. The value is a decimal string taken from the latest premium index snapshot. While no fresh snapshot is available for the market, the field is returned as an empty string instead. The same release repoints `index_price` and `funding_rate` to that premium index source. Field names and the decimal-string format are unchanged, so no integration change is required. `index_price` now carries the index the contract actually tracks; while the index is unavailable it falls back to the last traded price of the corresponding spot market, then to the last traded price of the futures market itself, and returns `"0"` when neither has traded. ### Maintenance status on order history **New `maintenance` order status and status filter on `POST /api/v4/trade-account/order/history` and `POST /api/v4/trade-account/order/history/query`** When a market enters planned maintenance, the platform cancels the orders that are open on it. Those orders now carry a dedicated `maintenance` status on both order-history endpoints, so an integration can tell a maintenance cancellation from one the user or a risk rule triggered. `POST /api/v4/trade-account/order/history` accepts `MAINTENANCE` as the `status` filter and returns `MAINTENANCE` in the response, matching the uppercase status set of that endpoint. Maintenance cancellations are no longer reported as `CANCELED`, so the `CANCELED` filter excludes maintenance records. `POST /api/v4/trade-account/order/history/query` accepts `maintenance` as the `status` filter and returns the same lowercase value in the response `status` field, matching the lowercase outcomes of that endpoint. Maintenance records carry an empty `delistingKind`, so the `status` field is the discriminator, and a request that omits `status` returns maintenance records next to the delisting records. ### Single-market fee endpoint documented **New reference page for `POST /api/v4/market/fee/single`** `POST /api/v4/market/fee/single` returns the effective maker and taker fee for one market. The endpoint has been available for some time but was never documented; the new reference page covers the request body, the response fields, and the validation errors. Use it when only one market matters — `POST /api/v4/market/fee` returns the account's default fees and every custom override at once. ## bankBic parameter for SEPA and bank-rail fiat withdrawals **New `bankBic` request parameter on `POST /api/v4/main-account/withdraw` and `POST /api/v4/main-account/withdraw-pay`** The withdrawal endpoints now accept a `bankBic` parameter carrying the beneficiary bank's BIC (SWIFT) code. It is required when the fiat provider is one of `SEPA`, `SEPA_CLEAR_JUNCTION`, `SEPA_BCB_GROUP`, `FINCI`, `ZEN`, or `BANKING_CIRCLE`, and identifies the destination bank for bank-rail payouts. ## Funding cap and floor on futures markets list **New `funding_cap` and `funding_floor` fields on `GET /api/v4/public/futures`** Each futures market entry now returns the bounds that the funding rate can reach: `funding_cap` (upper) and `funding_floor` (lower). Use the fields to model worst-case funding costs in trading algorithms instead of hardcoding exchange-wide limits. Both fields are decimal strings served from the last successfully refreshed funding snapshot, so a temporary source outage does not drop the values; both return `null` only when no snapshot has been loaded since service start. ## Delisting date on Market Info **`delistedAt` field on `GET /api/v4/public/markets`** Every market entry carries `delistedAt` — the announced delisting date as a Unix timestamp in seconds, or `null` when no delisting is announced. The field has been live since June 2026; this entry marks the point it became documented. A market with an announced delisting stays tradeable until the delisting runs; once the delisting runs, the platform cancels the active orders on the market and drops the market from the response. An announcement can be rescheduled or canceled, so read the value on each poll rather than caching the value for the lifetime of an integration. ## Closed-position PNL on Collateral Trading **New `POST /api/v4/collateral-account/positions/closed-pnl` endpoint** The Collateral Trading API now returns one aggregated profit-and-loss record per closed position — the same closed-position PNL the trading terminal shows. Each record carries `grossPnl` (realized PNL with trading fees already deducted), `netPnl` (`grossPnl` minus `totalFunding`), volume-weighted average entry and exit prices, total closed size, and informational fee totals. The optional `startDate`/`endDate` window filters by position close time, and a position opened before the window still returns complete lifetime aggregates. The `amount` field always returns `"0"` for closed positions. ## RPI maker fee premiums on Query Market Fees **New `rpi_maker_fee_premium` and `futures_rpi_maker_fee_premium` fields on `POST /api/v4/market/fee`** The Query Market Fees response returns the RPI maker fee premium, an additional fee component applied on top of the maker rate when a Retail Price Improvement (RPI) order executes. `rpi_maker_fee_premium` covers spot and margin markets; `futures_rpi_maker_fee_premium` covers futures markets. The effective RPI maker rate equals the base maker rate plus the applicable premium. The endpoint returns both fields for every account, regardless of whether the RPI order mode is enabled; each field returns `null` when no premium is configured for the account, and a premium configured as zero is returned as `"0"`. ## Express Withdraw for B2B partners **New `POST /api/v4/main-account/express-withdraw/token` endpoint for B2B partners** Express Withdraw lets an approved B2B partner charge a specific amount from a WhiteBIT user's balance through a signed, single-use payment token valid for 90 seconds. The partner integrates one endpoint; the user confirms the exact ticker and amount on a WhiteBIT-hosted page, and the funds settle instantly, off-chain, and fee-free into the partner's Main balance. Express Withdraw is not available to everyone: the endpoints are available only for B2B partner services and require a separate approval process. Request access at [https://institutional.whitebit.com/](https://institutional.whitebit.com/). ## Granted permissions on OAuth API key info **New `permissions` array on `GET /oauth2/api-key/info`** `GET /oauth2/api-key/info` now returns a `permissions` array alongside `exists`, `isEnabled`, and `externalId`. Each entry is a permission group with a locale-independent `name` (for partner-side logic), a locale-dependent `title` (display only), and a `urls` list of `{ url, enable }` pairs reflecting what the user granted during the OAuth handshake. The array is empty when no key exists; for a disabled key the array still reflects the grant-time permission set, so the partner can show the original scope. ## Abbreviated Self-Trade Prevention mode values **`stp` accepts `cb`, `cn`, `co`; long-form values deprecated** The `stp` parameter on trade endpoints now uses abbreviated mode values: `cb` (cancel both), `cn` (cancel new), and `co` (cancel old); `no` is unchanged. The legacy values `cancel_both`, `cancel_new`, and `cancel_old` are deprecated. The long-form values remain accepted with identical behavior until a deprecation deadline is announced, after which the API rejects the long-form values. Responses always return the abbreviated form, regardless of which variant the request used. The parameter is documented on the five spot order endpoints (limit, market, stock market, stop-limit, stop-market) and the five collateral order endpoints (limit, market, stop-limit, trigger-market, OCO). ## Travel Rule API **New endpoints and structured format for Travel Rule compliance** The Travel Rule API enables B2B clients to submit originator and beneficiary data for cryptocurrency transactions as required by FATF and MiCA regulations. Available for accounts registered in the European Economic Area (EEA). **New endpoints:** * `POST /api/v4/travel-rule/vasps` — Retrieve the list of available VASPs for travel rule submissions. * `POST /api/v4/travel-rule/deposit/verification` — Submit originator data for deposits pending verification. **Updated `travelRule` format on withdrawals:** The `travelRule` object on `POST /api/v4/main-account/withdraw` now uses a structured format with `walletType`, `beneficiary`, and `vasp` objects. The legacy flat format is deprecated. ## TradFi Futures markets on Market Info **New `tradfiFutures` market type and `isTradFiFutures` flag on `GET /api/v4/public/markets`** `GET /api/v4/public/markets` returns traditional-finance (TradFi) futures markets, futures contracts on traditional financial assets such as equities (for example, `AAPL_USD`). A TradFi market carries `type: tradfiFutures` together with `isTradFiFutures: true`. Availability is region-gated: markets the account is not eligible to trade are omitted from the response entirely and do not appear under any other market type. ## Retail flag on Create Limit Order and Bulk Limit Order **New `retail` request parameter enables API clients to take RPI-maker liquidity** A new optional `retail` boolean parameter on `POST /api/v4/order/new` and `POST /api/v4/order/bulk` marks an order as a retail-source taker. A retail taker is eligible to match against orders submitted by RPI makers and may receive price improvement at execution. The retail designation was previously available only on non-API sources (web, mobile, TV); approved WaaS/CaaS clients can now take RPI orders via API. **Validation:** * `retail=true` requires the Retail flag enabled on the account; the API returns error code `42` otherwise. * `retail=true` cannot be combined with `rpi=true`; the API returns error code `41` otherwise. * The flag has no effect on `postOnly=true` orders, because post-only orders are makers and cannot be retail takers. ## Fast API Key via OAuth **New OAuth flow for partner-issued API keys** Partner platforms can now issue a WhiteBIT API key on behalf of a WhiteBIT user through the OAuth API key consent flow. The flow uses Authorization Code with PKCE (S256), a 4-hour access token without refresh, and partner-scoped IP restrictions on the resulting key. Three new OAuth2 endpoints support the flow. **New endpoints (global server only — `https://whitebit.com`):** * `GET /oauth2/api-key/info` — Check whether a partner-issued API key already exists for the authenticated user and OAuth2 client pair. * `GET /oauth2/api-key/{externalId}/secret` — Retrieve the API secret once. Subsequent calls return `409`. * `DELETE /oauth2/api-key/{externalId}` — Delete a partner-owned API key. Sends an email notification to the user. **New OAuth scopes:** `apikeys.create`, `apikeys.read`, `apikeys.delete`. ## Position History API update **Breaking change: `positionSide` field removed from Position History response** The `POST /api/v4/collateral-account/positions/history` endpoint no longer returns the `positionSide` field. Two new fields replace it: `side` (same enum as the removed field — `LONG`, `SHORT`, `BOTH`) and `isHedge` (a boolean indicating whether the position was opened in hedge mode). The combination lets integrations attribute closed-position records to a specific direction and account mode for P\&L tracking, compliance reporting, and strategy reconstruction. **Migration guide:** * Replace any reader of `positionSide` from `/positions/history` with `side`. The enum is unchanged: `LONG`, `SHORT`, `BOTH`. * Read `isHedge` to determine whether the record was produced under hedge mode (`true`) or one-way mode (`false`). * Other endpoints that return `positionSide` (`/positions/open`, `/conditional-orders`, order-create requests) are unchanged. **Sunset date:** April 29, 2026. **Replacement:** Use `side` and `isHedge` on the same endpoint. See [v4 - Positions history](/api-reference/trading/positions-history). **Impact:** Integrations parsing the response of `POST /api/v4/collateral-account/positions/history` and reading `positionSide` must migrate to `side` and `isHedge`. Other endpoint integrations are not affected. ## Bulk cancel orders endpoint **Cancel up to 100 spot orders in a single request** The new `POST /api/v4/order/cancel/bulk` endpoint cancels up to 100 spot orders in a single request. Each item identifies a target order by `market` plus exactly one of `orderId` or `clientOrderId`. The response array preserves the order of the input — `response[i]` corresponds to `request.orders[i]`. ## Reduce-only order parameter **Position-closing guarantee for collateral orders** A new `reduceOnly` boolean parameter for collateral order endpoints. When set to `true`, the order can only decrease or close an existing position — the order never increases the position or opens a new one. **Behavior:** * If the order amount exceeds the current position size, the system automatically reduces the order to match * The API returns error code `116` if no open position exists or the order direction matches the position direction * Pending reduce-only orders are auto-canceled with status `AUTO_CANCELED_REDUCE_ONLY` when the associated position closes **Supported on 6 collateral order creation endpoints:** The `reduceOnly` field also appears in the response of [query active orders](/api-reference/trading/query-unexecuted-orders), [query executed orders](/api-reference/trading/query-executed-orders), and [query conditional orders](/api-reference/trading/query-unexecuted-conditional-orders). **WebSocket channels:** The `reduce_only` field is added to the [Orders Pending](/websocket/account-streams/orders-pending) and [Orders Executed](/websocket/account-streams/orders-executed) channels — both in query responses and real-time update events. See [Order Types — Reduce-only orders](/concepts/order-types#reduce-only-orders) for full details. ## clientOrderId uniqueness scope change **Breaking change: `clientOrderId` is now unique only among open orders, not for a fixed time window** The uniqueness rule for `clientOrderId` on spot and collateral order creation changed. Uniqueness is now enforced only among the account's open (pending) orders on the same market. Once a previous order is filled or canceled, the same `clientOrderId` can be reused, including on the same market. The previous time-based uniqueness window no longer applies. **Impact on retry and deduplication logic:** Integrations that relied on a fixed-time uniqueness window to suppress duplicate submissions should not assume a resubmitted `clientOrderId` will be rejected after the original order leaves the open state. Before resubmitting an order whose response was not received, check whether an order with that `clientOrderId` already exists: * [Query unexecuted orders](/api-reference/trading/query-unexecuted-orders) (`POST /api/v4/orders`) — search open orders by `clientOrderId`. * [Query executed orders](/api-reference/trading/query-executed-orders) (`POST /api/v4/trade-account/order/history`) — search filled and canceled orders by `clientOrderId`. If the order is found in either result, the original submission was accepted and no retry is needed. ## Previous Changes ## Auto-Deleveraging (ADL) **Futures-market final-stage liquidation mechanism** WhiteBIT futures markets now apply Auto-Deleveraging as the final stage of liquidation, activated only when standard market liquidity cannot fully cover a liquidated position. ADL closes profitable counterparty positions on the opposite side at a calculated price, ranked by an internal Rating, ensuring no user balance becomes negative. **Integrator-relevant facts:** * ADL fills carry `source: "adl"` on the `ordersExecuted` WebSocket stream and a `client_order_id` of the form `adl__!`. Over REST order history — where the payload does not include `source` — match the `adl_` `client_order_id` prefix. The `reduce_only` flag remains `false` on ADL inserts, so do not use it for identification. * Pending reduce-only orders auto-cancel with the existing `AUTO_CANCELED_REDUCE_ONLY` status when ADL closes a counterparty position. No ADL-specific cancel status was introduced. * ADL Grade (0–4) indicates a position's place in the per-market ADL ranking, with Grade 4 corresponding to the asymptotic top 5% of ranked positions. ## Deprecation: OCO and OTO cancel endpoints **`POST /api/v4/order/oco-cancel` and `POST /api/v4/order/oto-cancel` are being retired** WhiteBIT is discontinuing support for the two dedicated conditional-cancel endpoints. Cancel OCO and OTO orders through [`POST /api/v4/order/conditional-cancel`](/api-reference/trading/cancel-conditional-order), which handles both order types on every collateral market. **Migration guide:** * Replace calls to `POST /api/v4/order/oco-cancel` and `POST /api/v4/order/oto-cancel` with `POST /api/v4/order/conditional-cancel`. * Send the conditional order `id` in place of `orderId` or `otoId`. The value is the same identifier, returned as `id` by [query unexecuted conditional orders](/api-reference/trading/query-unexecuted-conditional-orders). * An integration that cancels OCO orders by `clientOrderId` must resolve the client order id to the conditional order `id` first through [query unexecuted conditional orders](/api-reference/trading/query-unexecuted-conditional-orders). The replacement endpoint does not accept `clientOrderId`. * Expect an empty array in the response. `POST /api/v4/order/oco-cancel` returns the canceled `stop_loss` and `take_profit` legs; the replacement does not. An integration that logs the canceled legs can read the final leg state from [query executed orders](/api-reference/trading/query-executed-orders), within a 31-day request window reaching back 6 months. For B2B accounts, canceled orders are not recorded in order history; contact support or the assigned account manager to retrieve canceled-leg data. **Impact:** Integrations calling either endpoint must migrate. Integrations that cancel OCO orders by `clientOrderId`, or that read the canceled legs from the response, need an extra lookup rather than a direct swap. **Backward compatibility:** Both endpoints keep working until the sunset date. **Sunset date:** To be announced. ## Mining Pool API **Comprehensive mining pool management endpoints** Introduced a complete Mining Pool API with 10 endpoints for managing mining operations, including account monitoring, payout configuration, worker management, and watcher link generation. **Public endpoints:** * Pool statistics and connection information **Mining account management:** * Reward history with pagination * Account-level hashrate monitoring with configurable intervals (5m, 1h, 24h) * Fee and stratum connection details **Payout configuration:** * Get and set payout destination (main balance or external BTC address) * Support for all standard Bitcoin address formats **Worker monitoring:** * List online workers with pagination * Individual worker hashrate history **Watcher links:** * Create read-only access links with granular permissions (dashboard, rewards, workers) * Configurable expiration periods (1h, 24h, 7d, always) * List active watcher links All authenticated endpoints require the MINING\_POOL feature to be enabled on the API key. ## Mining Account Management **Create and list mining accounts** Added endpoints to create and manage mining pool accounts programmatically. **Account creation:** * Create named mining accounts with optional referral codes * Unique account names with alphanumeric and underscore support * Automatic validation for duplicate names **Account listing:** * Retrieve all mining accounts or filter by name * Results sorted by creation date (newest first) All endpoints require the MINING\_POOL feature to be enabled on the API key. ## API Documentation Updates **Sub-account transfer endpoints: add transactionId for correlation** The response of `/api/v4/sub-account/transfer` and `/api/v4/sub-account/transfer/history` includes the `transactionId` field. Use `transactionId` to correlate transfer operations with transfer history records. The `id` field in transfer history is deprecated. Replace `id` with `transactionId`. ## Documentation Updates **Clarified Book Ticker stream update interval** Refined the description of the Book Ticker WebSocket stream to explicitly state instant BBO snapshot with incremental updates. ## Flex Earn Endpoints **Introduced Smart Flex private endpoints** Added documentation for Smart Flex (Flex Earn) endpoints: list plans, manage investments, view histories, and configure auto-reinvestment. ## API Documentation Updates **Enhanced Query executed orders documentation** Updated documentation for `/api/v4/trade-account/order/history` endpoint to clarify date range filtering capabilities with `startDate` and `endDate` parameters. ## Public API Update **New Funding History endpoint** Added new endpoint `/api/v4/public/funding-history/{market}` to retrieve funding rate history for futures markets. ## Private API Update **Issue JWT Token for Private API** New endpoint to issue JWT token for private API access. **Issue card token using JWT** New endpoint to issue a card token using JWT for secure transactions. **Withdraw endpoint update** Address now accepts card tokens for withdrawals. ## Public WebSocket Update **Added BookTicker WebSocket stream** New bookTicker stream added to WebSocket API, providing real-time updates of best bid/ask prices and quantities for markets. Includes subscription (bookTicker\_subscribe) and unsubscription (bookTicker\_unsubscribe) methods for managing the data feed. ## Trade Engine Update **Event time and update id introduced in WebSocket events** WebSocket events now include `event_time` and `update_id` fields. The `event_time` field provides the timestamp of the event, while the `update_id` field is a unique identifier for each update, allowing for better tracking and synchronization of events. **Hedge mode support** The Hedge mode is now available for all users. This mode allows holding both long and short positions in the same asset simultaneously, providing greater flexibility in managing trades. **Queries Limited to the Last 6 Months** To enhance performance and focus on the most relevant data, the API limits data queries to the past 6 months. Data can be retrieved up to six months old from the current date. ## Withdraw update **HTTP Main V4 API - Withdraw** The `paymentDescription` field is now mandatory for withdrawal requests from whitebit-tr.com. ## Travel Rule Update **HTTP Main V4 API - Travel Rule** Added new statuses DEPOSIT\_TRAVEL\_RULE\_FROZEN (27) and DEPOSIT\_TRAVEL\_RULE\_FROZEN\_PROCESSING (28) to the deposit endpoint. ## Convert History Update **HTTP Trade V4 API - Convert** Added 30 days date range limit for convert history and default values for `from` and `to` parameters. ## Deposit and Withdrawal Updates **HTTP Main V4 API - Birth Date Addition** Added beneficiary.birthDate field (Format: YYYY-MM-DD) to withdrawal requests and customer.birthDate (Format: YYYY-MM-DD) to deposit requests. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.