Bybit API Integration in Mobile Crypto Applications
Bybit V5 API is a unified interface that merged Spot, Linear, Inverse, and Option under one base URL. Sounds convenient until you realize that the same parameters (category, symbol) are interpreted differently depending on the route. Mobile integration requires clear architecture-level distinction of categories.
Authentication and Signature in V5
Bybit uses HMAC-SHA256 like most exchanges, but with a difference: parameters for GET requests concatenate as timestamp + api_key + recv_window + queryString, and for POST—timestamp + api_key + recv_window + rawBody. Request body is transmitted as JSON (not form-encoded), which is atypical for exchange REST APIs.
The error ret_code: 10002 ("Request timestamp expired") on Android appears even with recvWindow=20000 if the device uses an NTP server with lag. The solution is the same as Binance—cache serverTime from /v5/market/time and subtract local offset.
API key rotation is a separate story. Bybit supports IP-whitelist at the key level: if a user works over mobile internet with a dynamic IP, whitelist doesn't apply. Inform users about the risks of open keys (without IP binding) and remove withdrawal permissions from mobile keys by default.
WebSocket V5: Differences from Previous Versions
wss://stream.bybit.com/v5/public/spot is public stream. wss://stream.bybit.com/v5/private is private, requiring authentication via auth operation immediately after connection:
{
"op": "auth",
"args": ["api_key", "expires", "signature"]
}
expires is Unix timestamp in milliseconds plus 1000 (valid for 1 second). Signature is HMAC-SHA256("GET/realtime" + expires). The error {"op":"auth","success":false,"ret_msg":"api_key not found"} usually means the key was created for Testnet, but the connection is to Mainnet.
Bybit doesn't require periodic listenKey renewal—authorization is WebSocket-session level. But the session disconnects after prolonged inactivity. Keepalive via {"op":"ping"} every 20 seconds is mandatory.
On iOS, background mode requires VoIP entitlement or a background task via BGTaskScheduler if you need order execution tracking. Otherwise—push notifications via a server component only.
Bybit-Specific Features for Mobile Traders
Bybit supports Unified Trading Account (UTA)—mode where margin is split between Spot, Derivatives, and Options. This means GET /v5/account/wallet-balance returns one account with multiple coin records and aggregated totalEquity. Parsing requires protection against null in unrealisedPnl and cumRealisedPnl fields—they're absent for Spot.
Order Book via WebSocket stream orderbook.{depth}.{symbol} comes as two message types: type: "snapshot" (full snapshot) and type: "delta" (changes). Local order book implementation: apply delta to snapshot, remove levels with size: "0", maintain sorted structure (TreeMap in Android, SortedDictionary in .NET). Typical bug—ignoring u (update ID) and breaking delta application order on reconnect.
Stack and Approach
For native Android: Retrofit 2 + OkHttp + kotlinx.serialization (faster than Gson for large order book JSON). For iOS: URLSession + Combine + Codable with custom KeyDecodingStrategy for Bybit's snake_case fields.
Test on Bybit Testnet (api-testnet.bybit.com)—faucet available for test coins. Mandatory coverage: order book delta application logic. Load pre-recorded WebSocket sessions and replay them in MockWebServer.
Project assessment starts with clarification: UTA or Classic Account needed, which categories (Spot / Linear / Inverse), Copy Trading API support. Basic integration timeline—2–3 weeks. Full trading module—5–10 weeks.