Skip to main content
The Market-Making Program provides dedicated infrastructure for professional liquidity providers: maker-fee rebates, colocation, and a 33-endpoint API subset reachable from inside the matching-engine zone.

Market-Making Program overview

The Market-Making Program offers tiered maker-fee rebates based on 30-day rolling trading volume, with separate tiers for spot and futures. Negative maker fees are rebates — the exchange pays the market maker for each maker order filled. Rates and volume breakpoints change over time and are not duplicated here. For current fees and tier requirements, see the Market-Making Program page, the trading fees page, or the VIP program. How to apply: Contact institutional@whitebit.com with trading volume history and target markets. Program benefits beyond fees:

Colocation setup

Colocation provides low-latency API access from AWS infrastructure co-located with the WhiteBIT matching engine. The account manager provides the specific AWS region, availability zone, and connection endpoints during onboarding. EC2 sizing recommendations:
  • Network: up to 10Gbit bandwidth
  • CPU: minimum 4 vCPU cores
  • Low-performance VPS instances result in higher latency
Both REST API and WebSocket connections are available via colocation. Contact the designated account manager for connection details including base URLs and availability zone placement.
Colocation endpoints are a SUBSET of the full WhiteBIT API. Only the 33 endpoints listed below are available via colocation infrastructure. All other API endpoints must be accessed through the standard public API.
See the Colocation page for additional infrastructure details.

Available colocation endpoints

The colocation infrastructure exposes 33 endpoints organized into three categories: spot trading (15), collateral trading for both Margin and Futures (14), and utility (4).

Spot trading (15 endpoints)

EndpointDescription
POST /api/v4/trade-account/balanceTrade account balance
POST /api/v4/trade-account/executed-historyExecuted order history
POST /api/v4/trade-account/orderSingle order details
POST /api/v4/trade-account/order/historyOrder history
POST /api/v4/ordersActive orders list
POST /api/v4/order/cancelCancel an order
POST /api/v4/order/newPlace a limit order
POST /api/v4/order/bulkPlace up to 20 limit orders
POST /api/v4/order/modifyModify an existing order
POST /api/v4/order/marketPlace a market order
POST /api/v4/order/stock_marketPlace a stock market order
POST /api/v4/order/stop_limitPlace a stop-limit order
POST /api/v4/order/stop_marketPlace a stop-market order
POST /api/v4/order/kill-switchSet or cancel the kill-switch timer
POST /api/v4/order/kill-switch/statusCheck kill-switch status

Collateral / Margin and Futures trading (14 endpoints)

EndpointDescription
POST /api/v4/collateral-account/balanceCollateral account balance
POST /api/v4/collateral-account/balance-summaryCollateral balance summary
POST /api/v4/collateral-account/summaryCollateral account summary
POST /api/v4/collateral-account/leverageSet leverage
POST /api/v4/collateral-account/positions/openOpen positions
POST /api/v4/collateral-account/positions/historyPosition history
POST /api/v4/collateral-account/funding-historyFunding history
POST /api/v4/oco-ordersOCO orders
POST /api/v4/order/collateral/limitCollateral limit order
POST /api/v4/order/collateral/marketCollateral market order
POST /api/v4/order/collateral/stop-limitCollateral stop-limit order
POST /api/v4/order/collateral/trigger-marketCollateral trigger-market order
POST /api/v4/order/collateral/ocoCollateral OCO order
POST /api/v4/order/collateral/bulkCollateral bulk orders
API naming convention: WhiteBIT’s API uses “collateral” endpoints for both Margin and Futures trading. The market pair determines the product: spot pairs (e.g., BTC_USDT) for Margin, perpetual pairs (e.g., BTC_PERP) for Futures. All endpoints under /api/v4/order/collateral/ and /api/v4/collateral-account/ serve both products.

Utility (4 endpoints)

EndpointDescription
POST /api/v4/profile/websocket_tokenGenerate WebSocket authentication token
GET /api/v4/public/pingServer health check
GET /api/v4/public/timeServer time
POST /api/v4/market/feeQuery market fee for a pair
For endpoints not listed above, use the standard WhiteBIT API at https://whitebit.com.

Quoting strategy

Quoting on WhiteBIT uses limit orders placed via individual endpoints or POST /api/v4/order/bulk (up to 20 limit orders per request), paired with the depth and bookTicker WebSocket channels for price input. Bulk vs individual: bulk reduces wire and auth overhead and gives atomic same-timestamp placement of a quote ladder. The bulk response only returns once every leg in the batch is processed. Pipelined individual orders give faster per-leg acknowledgment for clients optimized for that pattern. Use bulk for atomic quote refreshes and less-optimized clients; use individual orders when lowest per-leg ack latency matters most. RPI mode: Each order item in /order/bulk can set rpi: true to enable Retail Price Improvement (RPI) mode. RPI orders are post-only and hidden from public depth and bookTicker feeds. They remain visible in the exchange UI order book (web/mobile) — capturing UI-driven retail flow rather than algorithmic flow consuming the public feed. RPI executions use an account-specific fee or rebate model. Incompatible with ioc. RPI is a flow-segmentation tool, not a default MM primitive — fit depends on volume targets and the account’s fee arrangement. See the API Reference and glossary entry. Real-time orderbook: Subscribe to the depth WebSocket channel for real-time orderbook updates. See the WebSocket Quickstart. Order modify: POST /api/v4/order/modify — change an existing order’s price, amount, or activation price. The matching engine internally cancels the original order and creates a replacement with a new orderId, so modify does NOT preserve queue priority. Use clientOrderId as the stable identifier across modifications. Identify the target by orderId OR clientOrderId — never both. See the API Reference. For how the engine sequences orders — price-time priority, participant fairness, and latency factors — see Matching engine. Kill-switch (circuit breaker): POST /api/v4/order/kill-switch — sets a timeout; if the endpoint is not called again before it expires, the kill-switch cancels every active order on the account. The deadman trigger for process crashes, lost connectivity, and operator absence. See the API Reference.
  • Configuration: set the timeout period; the timer resets on each API call to the kill-switch endpoint
  • Scope: pass the optional types array ("spot", "margin", "futures") to restrict the breaker to a subset of order types — useful when running spot market-making alongside futures positions you do not want to kill
  • Check status: POST /api/v4/order/kill-switch/status — see the API Reference
Self-Trade Prevention: Market makers providing two-sided quotes (bid + ask) must understand STP behavior to avoid self-trades. When a new order would match against an existing order from the same account, the STP mechanism cancels the new order, the existing order, both, or neither — depending on the stp mode passed at order placement. The default mode (no) allows self-trades, which is usually not what a two-sided quoter wants. See Self-Trade Prevention for the available modes.
# Place a bulk order (up to 20 limit orders). Each order item carries its
# own "market" field — there is no top-level market parameter.
curl -X POST "https://whitebit.com/api/v4/order/bulk" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "orders": [
      {"market": "BTC_USDT", "side": "buy",  "amount": "0.01", "price": "60000", "clientOrderId": "quote-bid-1"},
      {"market": "BTC_USDT", "side": "buy",  "amount": "0.01", "price": "59900", "clientOrderId": "quote-bid-2"},
      {"market": "BTC_USDT", "side": "sell", "amount": "0.01", "price": "60200", "clientOrderId": "quote-ask-1"},
      {"market": "BTC_USDT", "side": "sell", "amount": "0.01", "price": "60300", "clientOrderId": "quote-ask-2"}
    ],
    "request": "/api/v4/order/bulk",
    "nonce": "YOUR_NONCE"
  }'

# Requote the top bid by clientOrderId. The response carries a new orderId;
# the clientOrderId is preserved so local tracking survives the modify.
curl -X POST "https://whitebit.com/api/v4/order/modify" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "market": "BTC_USDT",
    "clientOrderId": "quote-bid-1",
    "price": "60050",
    "request": "/api/v4/order/modify",
    "nonce": "YOUR_NONCE"
  }'

# Set a kill-switch with 60-second timeout. The timeout field is a string.
curl -X POST "https://whitebit.com/api/v4/order/kill-switch" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "market": "BTC_USDT",
    "timeout": "60",
    "request": "/api/v4/order/kill-switch",
    "nonce": "YOUR_NONCE"
  }'
For Go and PHP examples, see SDKs.

WebSocket workflow for market making

The market-making loop runs on real-time WebSocket data, not REST polling. Quote inputs arrive on depth (deep book) or bookTicker (top of book); inventory state arrives on balanceSpot; fill confirmations arrive on deals (executions) and ordersPending (state transitions including partial fills and cancels). Wire those four channels together to close the loop: market data drives the quote, REST order/bulk or order/modify places it, ordersPending confirms the state transition, deals confirms the fill, balanceSpot confirms the inventory delta, and the loop recomputes. The protocol primitives — connect, ping/pong, authorize, exponential-backoff reconnection, and the query-then-subscribe recovery pattern — are covered end-to-end in the WebSocket Quickstart.
ChannelTells youRecovery modelWhere to learn the protocol
depthFull orderbook (1/5/10/20/30/50/100 levels per market)Snapshot on subscribe, then incremental updates with update_id for gap detectionWS Quickstart — Subscribe to orderbook depth
bookTickerBest bid + best ask only — lighter than depth, ideal for top-of-book quotingSimple replacement on every changeBook Ticker channel. Note: bookTicker_update excludes RPI orders. Track RPI quotes via the private active-orders state.
balanceSpotAvailable + frozen balances per assetQuery-then-subscribe (balanceSpot_request then balanceSpot_subscribe)WS Quickstart — State recovery
ordersPendingActive order state transitions: placed, partially filled, canceledQuery first (ordersPending_request or REST POST /api/v4/orders), then subscribeBot Guide — WebSocket fill monitoring
dealsTrade execution events with price, amount, fee, deal-idQuery first (deals_request or REST POST /api/v4/trade-account/executed-history), then subscribeBot Guide — WebSocket fill monitoring
Futures additions. When quoting perpetuals (e.g. BTC_PERP), add two more channels:
ChannelTells youRecovery modelWhere to learn the protocol
positionsSnapshot of open collateral positions (size, entry price, liquidation price, PnL)Periodic full snapshot — full state arrives within ~1.5s of subscribingWS Quickstart — State recovery table
marginPositionsEventsPosition-change events (open, update, close, liquidation)Event-only — pair with positions for complete stateWS Quickstart — State recovery table
Canonical subscribe set (spot MM). Send these messages after the authorize handshake — the three private subscriptions will be rejected on an unauthenticated socket. For multi-symbol MM, repeat each *_subscribe per market or use the multiple-subscription flag where supported (see the depth subscribe parameters). To stop quoting on one pair without disrupting the others, send depth_unsubscribe or bookTicker_unsubscribe with that market name in params — only that market’s feed drops; an empty array unsubscribes from all markets on the stream.
[
  {"id": 10, "method": "depth_subscribe",         "params": ["BTC_USDT", 20, "0", true]},
  {"id": 11, "method": "balanceSpot_subscribe",   "params": ["USDT", "BTC"]},
  {"id": 12, "method": "ordersPending_subscribe", "params": ["BTC_USDT"]},
  {"id": 13, "method": "deals_subscribe",         "params": [["BTC_USDT"]]}
]
Note the asymmetry: ordersPending_subscribe takes a flat array of markets, deals_subscribe takes a single-element array containing the array of markets. The full schema lives in asyncapi/private/deals.yaml (rendered as the Deals channel page). For the full reconnect-with-fresh-token + auto-resubscribe pattern that wraps these subscriptions in production, see WS Quickstart — Reconnection and state recovery and the worked grid-bot example in the Bot Guide.

Infrastructure best practices

Three pieces are load-bearing in production: how the account is partitioned across strategies, how the socket recovers when it drops, and how requests stay under per-endpoint limits. Sub-accounts for strategy separation: Use sub-accounts to isolate different trading strategies or pair groups. Each sub-account has independent balances and can have dedicated API keys; transfers between sub-accounts are fee-free. Worked example: run the BTC_USDT spot MM book in one sub-account funded with its own USDT balance, and a directional ETH_USDT swing book in a second sub-account with its own balance and leverage limit. A drawdown that wipes the swing book’s collateral cannot pull capital from the MM book — the MM bot keeps quoting on its untouched balance, and the swing book’s API key has no authority over the MM sub-account. WebSocket connection management:
  • Authenticate after connecting: fetch a token via POST /api/v4/profile/websocket_token (rate limit: 10 requests per 60 seconds — cache the token across reconnects within its lifetime), then send {"id": N, "method": "authorize", "params": ["<token>", "public"]} on the socket. On {"result": {"status": "success"}}, subscribe to private channels such as balanceSpot, ordersPending, and deals
  • Implement automatic reconnection with exponential backoff
  • Re-subscribe to all channels after reconnection
  • Use the ping/pong mechanism to detect stale connections
  • After reconnecting, reconcile local state: call POST /api/v4/orders for the current active set and POST /api/v4/trade-account/executed-history for fills since the last-seen ID. Do not assume in-memory state survived the disconnect
  • See the WebSocket Quickstart for a full connection + auth example
Rate limit management:
  • Rate limits vary per endpoint — check Rate Limits for per-endpoint values
  • Use bulk orders (/order/bulk) to reduce request count: 20 orders per call vs. 20 individual calls
  • Use WebSocket for market data instead of polling REST endpoints
  • Maintain a per-endpoint token bucket sized to the limits in Rate Limits; back off when the bucket empties rather than retrying after a 429

Monitoring and safety

Set the kill-switch first; everything below is the loop that keeps it reset, the manual cancel that overrides it, and the balance and fee surfaces the loop reads from. Kill-switch configuration: Set the kill-switch timeout as the first action after connecting. Configure the timeout based on the maximum acceptable unmonitored period for the system. Reset the timer with each regular API call to the kill-switch endpoint. If the system crashes or loses connectivity, the kill-switch cancels all orders after the timeout expires. Emergency cancel: POST /api/v4/order/cancel/all — cancel every open order synchronously. Use the optional market field to scope to a single pair and the type array to scope to "spot", "margin", or "futures"; omit both to cancel everything on the account. This is the “big red button” for live traders; the kill-switch is the deadman timer for when you are not there. See the API Reference.
# Cancel all spot orders on BTC_USDT
curl -X POST "https://whitebit.com/api/v4/order/cancel/all" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "market": "BTC_USDT",
    "type": ["spot"],
    "request": "/api/v4/order/cancel/all",
    "nonce": "YOUR_NONCE"
  }'
Balance monitoring: Use the WebSocket balanceSpot channel for real-time balance updates, or poll POST /api/v4/trade-account/balance for periodic checks. Monitor for unexpected balance changes. Fee tracking: Use POST /api/v4/market/fee to pull the account’s global maker and taker fees plus any per-pair custom fees — the market request parameter is currently ignored, so the endpoint returns fees for all markets regardless. Filter the per-pair custom_fee map client-side. Fee tiers are based on 30-day rolling volume — monitor tier changes as volume accumulates. Look up tier breakpoints on the VIP program page or the trading fees page. Self-Trade Prevention: Understand the STP mode active on the account. Two-sided quoters hit STP frequently when bid and ask orders overlap. See Self-Trade Prevention for the available modes and behavior.

What’s Next

Colocation

AWS regions, EC2 sizing, and availability-zone placement for colocation onboarding.

Spot Trading API

Full endpoint documentation for all spot trading endpoints.

Self-Trade Prevention

STP modes and behavior for two-sided quoting.