> ## 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. ## 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` now 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`; both fields are always present on every market entry. Availability is region-gated: markets you are 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 you 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/collateral-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/spot-trading/query-unexecuted-orders), [query executed orders](/api-reference/spot-trading/query-executed-orders), and [query conditional orders](/api-reference/collateral-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/spot-trading/query-unexecuted-orders) (`POST /api/v4/orders`) — search open orders by `clientOrderId`. * [Query executed orders](/api-reference/spot-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 appear in standard order history with `source: "adl"` and `client_order_id: "adl_"`. The `reduce_only` flag remains `false` on ADL inserts — use `source` to identify them. * 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. ## 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.