Use this file to discover all available pages before exploring further.
Monitor account state across Main, Trade, and Collateral balances using REST endpoints and WebSocket streams. This guide covers balance queries, deposit/withdrawal tracking, order activity monitoring, and the decision framework for choosing between REST polling and WebSocket subscriptions. Applicable to any integration that needs real-time or periodic account state awareness.Payment processing integrations (deposit/withdrawal monitoring): focus on the balance monitoring and deposit/withdrawal tracking sections — Main balance does not support WebSocket streaming, so webhooks and REST polling are the primary mechanisms. Trading integrations (bots, dashboards): focus on balance monitoring and order activity monitoring via WebSocket for real-time state.
Main balance does not have a WebSocket subscription channel. Monitor Main balance changes — including deposit arrivals — via webhooks for real-time notifications or REST polling of POST /api/v4/main-account/history as a fallback.
import json, websockets, asyncioasync def monitor_balance(): async with websockets.connect("wss://api.whitebit.com/ws") as ws: # Authenticate first — see WebSocket Quickstart Step 4 for the full flow. # Without auth, balanceSpot_subscribe silently fails. # Subscribe to spot balance changes. # params: [] subscribes to all assets. # Pass specific tickers (e.g., ["USDT", "BTC"]) to filter updates. await ws.send(json.dumps({ "id": 1, "method": "balanceSpot_subscribe", "params": [] })) async for message in ws: data = json.loads(message) # Subscription confirmation has a "result" key. # Balance updates have a "method" key set to "balanceSpot_update". if "method" in data and data["method"] == "balanceSpot_update": for asset, info in data["params"].items(): print(f"Balance change: {asset} available={info['available']} freeze={info['freeze']}")asyncio.run(monitor_balance())
For real-time deposit and withdrawal notifications, configure webhooks. Webhook delivery includes up to 5 retries at 10-minute intervals (50-minute coverage window).Recommended reconciliation approach:
Primary: Webhooks — process events as they arrive for near-instant updates
Fallback: REST polling — periodically query the history endpoint to catch any events missed during webhook downtime or after the 50-minute retry window expires
See Webhooks for setup, signature verification, and event types. For the full deposit/withdrawal lifecycle including status state machines and fee calculation, see Payment Integration.
# Fetch all open orders for BTC_USDTopen_orders = send_request("/api/v4/orders", {"market": "BTC_USDT"})print(f"Open orders: {len(open_orders)}")for order in open_orders: print(f" {order['side']} {order['amount']} @ {order['price']} (ID: {order['order_id']})")
# Fetch order history for BTC_USDThistory = send_request("/api/v4/trade-account/order/history", {"market": "BTC_USDT"})for market, orders in history.items(): for order in orders[:5]: print(f" {order['side']} {order['amount']} @ {order['price']} — {order.get('type', 'unknown')}")
Reliability — webhooks for speed, REST for reconciliation
Open order monitoring
WebSocket
Real-time state changes (fills, cancellations)
Historical trades
REST
Paginated query over a time range
General guidance: Use REST for on-demand queries and historical data. Use WebSocket for any data that changes frequently and requires immediate reaction. Combine both: WebSocket for primary real-time flow, REST for startup state hydration and periodic reconciliation.
When using REST polling, align the interval with the use case and the endpoint rate budget. See Rate Limits & Error Codes for per-scope request limits.