Інтеграція API Bybit у мобільні крипто-додатки
Bybit V5 API — це унифікований інтерфейс, який об'єднав Spot, Linear, Inverse та Option під одним базовим URL. Звучить зручно, доки не зіткнешся з тим, що одні й ті ж параметри (category, symbol) інтерпретуються по-різному залежно від маршруту. Мобільна інтеграція потребує чіткого розграничення категорій на рівні архітектури.
Аутентифікація й підпис у V5
Bybit використовує HMAC-SHA256, як і більшість бирж, але є відмінність: параметри для GET-запитів конкатенуються як timestamp + api_key + recv_window + queryString, а для POST — timestamp + api_key + recv_window + rawBody. Тіло запиту передається як JSON (не form-encoded), що нетипово для REST API бирж.
Помилка ret_code: 10002 ("Request timestamp expired") на Android з'являється навіть при recvWindow=20000, якщо пристрій використовує NTP-сервер з затримкою. Рішення те ж, що з Binance — кешуємо serverTime з /v5/market/time та вираховуємо локальне смщення.
Ротація API-ключів — окрема історія. Bybit підтримує IP-whitelist на рівні ключа: якщо користувач працює через мобільний інтернет з динамічним IP, whitelist неприйнятний. Важливо передавати користувачам інформацію про ризики відкритих ключів (без IP-привʹязки) й видаляти дозволи на вивід коштів з mobile-ключів за замовчуванням.
WebSocket V5: відмінності від попередніх версій
wss://stream.bybit.com/v5/public/spot — публічний стрім. wss://stream.bybit.com/v5/private — приватний, потребує аутентифікації через auth operation одразу після підключення:
{
"op": "auth",
"args": ["api_key", "expires", "signature"]
}
expires — Unix timestamp у мілісекундах плюс 1000 (дійсний 1 секунду). Signature — HMAC-SHA256("GET/realtime" + expires). Помилка {"op":"auth","success":false,"ret_msg":"api_key not found"} зазвичай означає, що ключ створений для Testnet, а підключення на Mainnet.
Bybit не вимагає періодичного продовження listenKey — аутентифікація на рівні WebSocket-сесії. Але сесія перериває при довгій відсутності activity. Keepalive через {"op":"ping"} кожні 20 секунд — обов'язково.
На iOS фоновий режим потребує VoIP entitlement або фонової задачі через BGTaskScheduler, якщо потрібно відстежувати виконання ордерів. Інакше — лише push-сповіщення через серверний компонент.
Особливості Bybit для мобільних трейдерів
Bybit підтримує Unified Trading Account (UTA) — режим, де маржа розділяється між Spot, Derivatives та Options. Це означає, що запит баланцу (/v5/account/wallet-balance) може повернути один акаунт з кількома coin-записами й агрегованим totalEquity. Парсинг потребує захисту від null в полях unrealisedPnl та cumRealisedPnl — вони відсутні для Spot.
Order Book через WebSocket-стрім orderbook.{depth}.{symbol} приходить двома типами повідомлень: type: "snapshot" (повний снапшот) та type: "delta" (зміни). Реалізація локального стакана: застосовуємо дельту до снапшоту, видаляємо рівні з size: "0", утримуємо sorted структуру (TreeMap на Android, SortedDictionary у .NET). Типовий баг — ігнорування u (update ID) й порушення порядку застосування дельт при переподключенні.
Стек та підхід
Для нативного Android: Retrofit 2 + OkHttp + kotlinx.serialization (швидше за Gson для великих JSON-ответов стакана). Для iOS: URLSession + Combine + Codable з кастомним KeyDecodingStrategy для snake_case полів Bybit.
Тестуємо на Bybit Testnet (api-testnet.bybit.com) — доступен faucet для отримання тестових монет. Обов'язково покриваємо тестами логіку застосування orderbook delta: завантажуємо заранее записані WebSocket-сесії й відтворюємо їх у MockWebServer.
Оцінка проекту починається з уточнення: потрібен ліUTA або Classic Account, які категорії (Spot / Linear / Inverse), підтримка Copy Trading API. Період базової інтеграції — 2–3 тижні. Повний торговий модуль — 5–10 тижнів.







