Overview
Bybit is one of the leading cryptocurrency derivatives exchanges, with significant trading volumes across perpetual futures, options, and spot markets. Originally focused on derivatives trading, Bybit has expanded to offer a comprehensive platform covering USDT-margined perpetual contracts, COIN-margined inverse contracts, spot trading, options, and the Bybit Unified Trading Account (UTA) that consolidates multiple product types under a single account structure. For algorithmic traders, systematic trading firms, and portfolio management systems that operate in cryptocurrency derivatives markets, Bybit's API is a primary integration point for execution and market data.
Bybit's REST and WebSocket APIs have undergone significant evolution — the V5 API is the current unified interface that covers all product types through a consistent endpoint structure, replacing the earlier separate APIs for different product categories. V5 uses a consistent authentication mechanism, a consistent response format, and a unified WebSocket stream design across spot, linear (USDT-margined), inverse (COIN-margined), and options markets. Building against V5 from the outset, rather than the legacy APIs, produces integrations that cover all Bybit product types with a single integration approach.
The Bybit API has specific conventions and behaviours that production integrations must handle correctly. Authentication uses HMAC-SHA256 signing with timestamp and receive window parameters. Rate limits are enforced at multiple levels — IP-level limits for public endpoints and UID-level limits for private endpoints — with different limits for different endpoint categories. The WebSocket interface uses a topic subscription model where clients subscribe to specific data streams after connection. Order placement requires correct handling of Bybit's category parameter that distinguishes between spot, linear, inverse, and option trading.
We build Bybit integrations for algorithmic trading systems, portfolio tracking applications, automated strategy execution, and market data infrastructure that needs reliable, production-quality connectivity to Bybit's trading and data APIs.
What Bybit Integration Covers
Authentication and request signing. Bybit's V5 API uses HMAC-SHA256 request signing for authenticated endpoints — a consistent signing scheme across all product categories.
Signature construction: the Bybit V5 signature is computed from a concatenated string of the timestamp (milliseconds since Unix epoch), the API key, the receive window, and the request parameters (query string for GET requests, JSON body for POST requests). The HMAC-SHA256 hash of this concatenated string using the API secret as the key. The four required headers for authenticated requests: X-BAPI-API-KEY (the API key), X-BAPI-TIMESTAMP (the timestamp), X-BAPI-RECV-WINDOW (the receive window in milliseconds, default 5000, maximum 60000), and X-BAPI-SIGN (the computed HMAC-SHA256 signature).
API key configuration: Bybit API keys are created in the account settings with configurable permissions — read-only for account queries and market data, order permissions for trading, position permissions for position management. The principle of least privilege applied to API key configuration — trading systems receive only the permissions they require, withdrawal permissions never granted to automated trading keys.
Timestamp synchronisation: Bybit rejects requests with timestamps that differ from the server time by more than the receive window. The timestamp synchronisation check that compares the client's system time against Bybit's server time endpoint before starting the integration, and the periodic re-synchronisation that catches clock drift in long-running services.
Unified Trading Account structure. Bybit's Unified Trading Account (UTA) consolidates spot, linear, inverse, and options trading under a single account balance, with cross-margin netting that allows profits in one product to offset losses in another. Understanding the UTA structure is important for portfolio tracking and risk management integrations.
Wallet balance: the GET /v5/account/wallet-balance endpoint with accountType=UNIFIED for UTA accounts. The response includes the total equity, the available margin, the unrealised PnL, and the per-coin breakdown of holdings. The coinList array that shows the quantity, value, and margin contribution of each held asset.
Account modes: standard UTA mode where positions across product categories share margin, versus the separate margin modes for accounts that have not been upgraded to UTA. The account mode detection that determines which balance endpoints and position structures apply.
Order placement and management. The V5 order API for placing and managing orders across all product categories.
Order placement: the POST /v5/order/create endpoint for placing orders. The category parameter that specifies the product type — spot for spot trading, linear for USDT-margined perpetuals and futures, inverse for COIN-margined perpetuals and futures, option for options. Order types: Market for immediate execution at the best available price, Limit for price-specified resting orders. Time-in-force: GTC (Good Till Cancelled), IOC (Immediate or Cancel), FOK (Fill or Kill), PostOnly for maker-only orders that are cancelled rather than crossing the spread.
Order parameters: symbol for the trading pair, side (Buy or Sell), qty for the order size. For linear and inverse contracts, the reduceOnly parameter for orders that should only reduce an existing position. The positionIdx parameter for hedge mode accounts — 0 for one-way mode, 1 for hedge mode buy-side position, 2 for hedge mode sell-side position.
Order response: the orderId (Bybit's assigned order identifier) and orderLinkId (the client-specified order identifier from the request) returned on successful order placement. The orderLinkId that allows the trading system to reference the order by its own identifier rather than waiting for Bybit's orderId.
Order queries: the GET /v5/order/realtime endpoint for open orders filtered by category, symbol, and order status. The GET /v5/order/history endpoint for historical orders with time range filtering. Single order lookup by orderId or orderLinkId.
Order cancellation: the POST /v5/order/cancel endpoint for cancelling a specific open order by orderId or orderLinkId. The POST /v5/order/cancel-all endpoint for cancelling all open orders for a specific category and optionally a specific symbol.
Order amendment: the POST /v5/order/amend endpoint for modifying the price or quantity of an open order without cancelling and replacing it — the order amendment that maintains the order's queue position while changing its parameters.
Batch order operations: the POST /v5/order/create-batch and POST /v5/order/cancel-batch endpoints for placing and cancelling multiple orders in a single API call — reducing the number of API calls required for strategies that place many orders simultaneously.
Position management. The V5 position API for querying and managing derivatives positions.
Position retrieval: the GET /v5/position/list endpoint that returns open positions filtered by category and optionally by symbol. The position data includes the symbol, the side (Buy/Sell), the size, the average entry price, the unrealised PnL, the cumulative realised PnL, the leverage, the liquidation price, and the position value.
Leverage setting: the POST /v5/position/set-leverage endpoint for configuring the leverage for a specific symbol. The buy-side leverage and sell-side leverage parameters for hedge mode accounts.
Position mode: the POST /v5/position/switch-mode endpoint for switching between one-way mode (a single net position per symbol) and hedge mode (separate long and short positions per symbol). The position mode that the trading strategy requires.
Trading stop: the POST /v5/position/trading-stop endpoint for setting stop-loss and take-profit levels on an open position without requiring a separate order. The position-level stop that is maintained by Bybit regardless of subsequent order activity.
WebSocket market data streams. Real-time market data via persistent WebSocket connections using Bybit's topic subscription model.
Connection management: the public WebSocket endpoint (wss://stream.bybit.com/v5/public/{category}) for market data, with separate endpoints for spot, linear, inverse, and option markets. The WebSocket connection lifecycle — connection establishment, ping/pong keepalive (Bybit requires a {"op":"ping"} message every 20 seconds to maintain the connection), and reconnection with re-subscription when the connection drops.
Subscription model: the {"op":"subscribe","args":["topic"]} message sent after connection establishment to subscribe to specific data streams. Multiple subscriptions combined in a single subscribe message. The confirmation response {"op":"subscribe","success":true} that confirms subscription acceptance.
Orderbook streams: the orderbook.{depth}.{symbol} topic for order book updates — orderbook.1.BTCUSDT for the best bid and ask only, orderbook.50.BTCUSDT for 50 levels, orderbook.200.BTCUSDT for 200 levels. The snapshot-and-delta model: the first message after subscribing is a full snapshot, subsequent messages are delta updates with additions, modifications, and deletions. The seq field that allows detection of missed updates requiring a re-subscription to re-synchronise.
Trade streams: the publicTrade.{symbol} topic for individual executed trades — price, size, direction (buyer/seller), and timestamp for each trade. The tick data stream for real-time price discovery and trade-based indicator calculation.
Kline streams: the kline.{interval}.{symbol} topic for OHLCV bar updates — the bar that is updated on each new trade and confirmed when the bar closes. Available intervals from 1 minute to 1 month plus tick-based intervals.
Ticker streams: the tickers.{symbol} topic for 24-hour statistics — bid price, ask price, last price, 24h change, volume, and open interest for derivatives contracts. The tickers.* wildcard for all symbols in a category simultaneously.
Liquidation streams: the liquidation.{symbol} topic for liquidation events — the forced liquidations that occur when positions reach their liquidation price. Liquidation data as a market sentiment indicator for derivatives strategies.
WebSocket private streams. Real-time account and order updates via authenticated WebSocket connections.
Private connection authentication: the private WebSocket endpoint (wss://stream.bybit.com/v5/private) requires authentication immediately after connection — the {"op":"auth","args":["{apiKey}","{expires}","{signature}"]} message where the signature is the HMAC-SHA256 of "GET/realtime{expires}" and expires is a future timestamp in milliseconds.
Order updates: the order topic for real-time order status changes — new orders, fills, partial fills, cancellations, and rejections. The order update that the trading system uses to maintain accurate order state without polling the REST API. The fill data in order updates — the executed price, quantity, and fees for each fill.
Position updates: the position topic for real-time position changes — position size changes after fills, PnL updates from funding payments, and liquidation events. The position update that keeps the trading system's position tracking aligned with Bybit's records.
Wallet updates: the wallet topic for account balance changes — margin balance, available balance, and unrealised PnL updates after fills and funding rate payments. The balance stream that provides real-time account equity for risk management calculations.
Execution history and trade records. Historical execution data for performance tracking and reconciliation.
Trade history: the GET /v5/execution/list endpoint for the history of executed trades — the order ID, the executed price and quantity, the trading fee, and the fee currency. The execution history that portfolio tracking and tax reporting systems use to reconstruct the complete trading record.
Funding history: the GET /v5/account/transaction-log endpoint for the history of funding payments, trading fees, and other account transactions. The funding rate payments that are a significant cost factor for strategies that hold perpetual futures positions overnight.
Market data REST API. Historical and reference data for backtesting and strategy initialisation.
Kline history: the GET /v5/market/kline endpoint for historical OHLCV bar data — up to 1000 bars per request with the start and end time range parameters for extended history retrieval. The category and symbol parameters that scope the data to the specific contract type.
Instrument information: the GET /v5/market/instruments-info endpoint that returns the trading specifications for all instruments — the minimum order size, the price tick size, the quantity step, and the leverage limits. The instrument specifications that order sizing calculations use to produce valid order parameters.
Orderbook snapshot: the GET /v5/market/orderbook endpoint for the current order book depth snapshot — used to initialise the local order book before connecting the WebSocket stream.
Funding rate history: the GET /v5/market/funding/history endpoint for historical funding rates — the periodic payments between long and short position holders in perpetual futures contracts. The funding rate history that strategies use to estimate carrying costs.
Rate Limit Management
Bybit enforces rate limits at both the IP level and the UID (user account) level, with different limits for different endpoint categories.
IP-level limits: public endpoints (market data) are limited by IP address — typically 10–20 requests per second depending on the endpoint. The shared IP limit that applies across all public API calls regardless of the API key used.
UID-level limits: private endpoints (trading, account) are limited by UID — the per-account rate limit that applies to order placement, cancellation, and account data queries. Bybit provides different rate limit tiers based on the account's VIP level, with higher-volume traders receiving higher rate limits.
Rate limit headers: Bybit includes rate limit information in response headers — the limit, the remaining requests, and the reset timestamp. The response header monitoring that tracks proximity to rate limits and adjusts request rates proactively.
Retry-After: Bybit returns a Retry-After header with 429 responses indicating when requests can resume. The backoff logic that respects this header rather than retrying immediately.
Technologies Used
- Rust — high-performance WebSocket stream processing, order book state management, low-latency order placement and management
- Python / ccxt — Bybit connectivity for algorithmic strategy development, backtesting, and research
- C# / ASP.NET Core — Bybit integration for .NET-based trading platforms and portfolio management systems
- TypeScript / Node.js — Bybit connectivity for web-based trading tools and dashboards
- WebSocket — real-time market data and private account stream connectivity
- REST / HTTP — order management, position data, account information, and historical market data
- HMAC-SHA256 — Bybit V5 request signing
- Redis — rate limit state, order state cache, WebSocket message distribution
- SQL (PostgreSQL / MySQL) — trade history, order records, position history, funding payment records
- Docker — containerised trading system deployment
- GitHub Actions — CI/CD pipeline for trading system deployment
Bybit in the Derivatives Trading Architecture
Bybit's strength in perpetual futures and the breadth of its derivatives offering make it a significant execution venue for systematic cryptocurrency derivatives strategies. The production Bybit integration — correct V5 authentication across all product categories, accurate real-time position tracking through the private WebSocket stream, comprehensive order lifecycle management, and the rate limit discipline that prevents disruption to trading operations — is the execution layer that systematic strategies depend on.
For strategies that trade across multiple exchanges, Bybit is one connector in a multi-venue execution architecture where a normalisation layer translates between the internal order model and each exchange's specific API conventions. The Bybit connector handles the Bybit-specific signing, the Bybit-specific parameter naming, and the Bybit-specific WebSocket authentication and subscription model — insulating the strategy layer from exchange-specific implementation details.
Reliable Bybit Connectivity for Cryptocurrency Derivatives
Bybit integrations built to production standards — correct HMAC-SHA256 V5 signing across all product categories, comprehensive rate limit management, accurate real-time order and position tracking through the private WebSocket stream, order book management with snapshot and delta update handling, and the operational monitoring that surfaces connectivity issues before they affect trading operations.