Integrating Bybit API into a Mobile Crypto App
We are a mobile development team with 5 years of experience in fintech and cryptocurrencies. We have implemented Bybit, Binance, and OKX API integrations for dozens of projects. In this article, we share practical experience: how to correctly sign requests, avoid time-related errors, set up WebSocket, and process the OrderBook. You will learn about the pitfalls specific to mobile platforms and how to overcome them.
Bybit V5 API is a unified REST+WebSocket interface that combines spot, linear and inverse contracts, and options. However, unification does not mean simplicity. On mobile devices, specific problems arise: differences in timestamp handling, difficulties with key rotation, and the need to maintain stable WebSocket connections when switching networks.
We cover three key areas: authentication and signing, WebSocket and OrderBook management, and the specifics of UTA (Unified Trading Account). For each, we provide a proven solution tested on real projects.
What difficulties arise when integrating Bybit V5 API into a mobile app?
Authentication and request signing
Bybit uses HMAC-SHA256, but the parameters for GET and POST are concatenated differently: for GET — timestamp + api_key + recv_window + queryString, for POST — timestamp + api_key + recv_window + rawBody. The body is sent as JSON, which is unusual for exchanges. According to Bybit documentation, the signature must be generated using HMAC-SHA256.
Error ret_code: 10002 ("Request timestamp expired") occurs even with recvWindow=20000 if the device uses an NTP server with latency. The solution is to cache serverTime from /v5/market/time and subtract the local offset. In our projects, we implement automatic time synchronization at every app launch.
API key security
Key rotation is a separate story. Bybit supports an IP whitelist, but for mobile users with dynamic IPs, this is not applicable. We recommend creating keys with limited permissions (no withdrawal) and storing them in Keychain (iOS) or EncryptedSharedPreferences (Android). This increases security twofold compared to simple storage in SharedPreferences.
How do we ensure WebSocket connection reliability and stability?
Bybit WebSocket V5 requires authentication via auth operation immediately after connection:
{ "op": "auth", "args": ["api_key", "expires", "signature"] } expires — Unix timestamp in milliseconds + 1000 (valid for 1 second). Signature — HMAC-SHA256("GET/realtime" + expires). Error api_key not found often means the key was created for Testnet, but the connection is to Mainnet. We include environment checks in code to eliminate this issue.
Keeping the connection alive
Bybit does not require periodic listenKey renewal — authentication lasts for the entire session. However, the session drops after prolonged inactivity. We send keepalive messages {"op":"ping"} every 20 seconds. On iOS, background mode requires a VoIP entitlement or a background task via BGTaskScheduler to monitor orders. If that's not possible, we use push notifications through a server component.
OrderBook processing
The OrderBook via the orderbook.{depth}.{symbol} stream arrives in two message types: snapshot and delta. Local order book implementation:
- Apply delta to snapshot.
- Remove levels with
size: "0". - Maintain a sorted structure (TreeMap on Android, SortedDictionary on iOS).
A typical mistake is ignoring the u (update ID) field, which leads to sequence corruption on reconnection. We guarantee that each message is processed in the correct order. For instance, in a recent project, we reduced order book update latency from 50ms to 10ms by optimizing the delta application logic.
What does our Bybit API integration work include?
| Stage | Result |
|---|---|
| Requirements analysis | Determining needed categories (Spot/Linear/Inverse), UTA or Classic mode |
| Architecture design | Authorization scheme, key storage, WebSocket architecture |
| Development | Implementation of REST and WebSocket clients, OrderBook handling |
| Testing | Unit tests, mock WebSocket sessions, testing on Testnet |
| Deployment and support | Documentation, help with App Store and Google Play publication |
Why is testing on Testnet important?
Bybit Testnet (`api-testnet.bybit.com`) provides a faucet to get test coins. This allows debugging all scenarios without risk of losing funds. We always cover delta application logic with tests: we load pre-recorded WebSocket sessions and replay them using MockWebServer.Timeline and cost
Basic REST/WebSocket integration: 2–3 weeks. Full trading module with UI: 5–10 weeks. The exact cost is calculated individually after clarifying requirements.
Contact us for a consultation — we will evaluate your project and offer the optimal solution.
| Product | Category | Level |
|---|---|---|
| Spot trading | Spot | Basic |
| Linear contracts | Linear | Advanced |
| Inverse contracts | Inverse | Advanced |
| Options | Option | Expert |
Our metrics: 5+ years in mobile development, 50+ successful projects, quality guarantee at every stage.
Contact us to start integration right now. Get a consultation for your project.







