How to Scrape Bybit Spot & Futures Market Data in 2026
Pull a unified snapshot of every Bybit spot, linear and inverse pair — price, 24h change, volume, funding rate and open interest — via the Bybit v5 API in seconds.
Bybit is one of the largest derivatives venues in crypto, and unlike a lot of sites covered on this blog, you don’t fight a bot wall to get its data — Bybit exposes a clean public v5 REST API. The real work isn’t anti-bot evasion; it’s normalization. Bybit splits its market into three categories — spot, USDT-margined linear perpetuals, and coin-margined inverse perpetuals — and each returns a different ticker shape. Stitching those into one consistent table, with numbers as numbers instead of strings, is the actual job. This guide covers the v5 API surface, what’s worth pulling, and how to get a unified full-market snapshot fast.
What’s worth extracting
Bybit’s ticker endpoints surface a rich per-pair snapshot. A unified record across categories includes:
- Symbol and category — the trading pair (BTCUSDT) and which market it belongs to (spot / linear / inverse).
- Last price — most recent traded price.
- 24h percent change — price move over the trailing 24 hours.
- 24h high / low — the day’s range.
- 24h base volume and quote turnover — volume in the base asset and the quote-currency turnover, the two numbers people conflate constantly.
- Best bid / ask — top of book, for spread and liquidity checks.
- Funding rate — futures only — the current funding rate for perpetuals, the core input for funding-arb.
- Open interest — futures only — total open contracts, the positioning signal.
- Timestamp — when the snapshot was taken.
For spot pairs, funding rate and open interest are simply absent — they don’t exist for spot. A good unified schema keeps those fields nullable rather than forcing a shape that doesn’t fit.
How the data is exposed
This is API data, not scraped HTML, so the relevant constraints are rate limits and endpoint structure, not Cloudflare. The Bybit v5 tickers endpoint is:
GET https://api.bybit.com/v5/market/tickers?category=spot
GET https://api.bybit.com/v5/market/tickers?category=linear
GET https://api.bybit.com/v5/market/tickers?category=inverse
The key efficiency win: each category returns every pair in that category in a single response. You don’t paginate per-symbol — one request per category gives you the whole spot market, one gives you all linear perps, one gives you all inverse perps. That’s why a full-market snapshot completes in seconds: it’s three API calls, normalized and merged.
A few things to know about the three shapes:
- Linear tickers carry
fundingRateandopenInterest; turnover is in USDT. - Inverse tickers also carry funding and open interest, but turnover and contracts are coin-margined, so the units differ from linear.
- Spot tickers omit funding and open interest entirely and report
volume24h/turnover24hdifferently from the contract markets.
All numeric fields come back as strings in the raw API. Converting "63420.5" to a real number before it lands in your dataset saves every downstream consumer from doing it themselves.
REST snapshots vs. the websocket
Bybit also offers a websocket that streams ticker updates in real time. The choice between them is about cadence, not capability:
- REST snapshot (this approach) — perfect for periodic full-market captures: a row per pair, every N minutes, for screeners, dashboards, backtesting archives and analytics. Cheap, simple, stateless.
- Websocket — needed only if you require sub-second tick-level updates for live execution. It’s more code, a persistent connection to keep alive, and overkill for analytics that refresh on a schedule.
For funding-rate monitoring, open-interest tracking, screeners and research, scheduled REST snapshots are the right tool. You don’t need a live socket to chart funding every five minutes.
▶ Run the Bybit Market Scraper — one run returns a unified, typed snapshot of every spot, linear and inverse pair with price, volume, funding rate and open interest. Three official API calls, normalized into flat rows, in seconds. Priced per row.
Build it yourself vs. use a managed scraper
The Bybit v5 API is well-documented and unauthenticated for public market data, so a basic puller is genuinely easy to write. The reasons people still reach for a managed version:
- Normalization is annoying. Three category shapes, string-to-number conversion, nullable futures-only fields, consistent column ordering — small, fiddly, and easy to get subtly wrong.
- Rate-limit handling. A scheduled job that runs every few minutes needs backoff and retry so a transient 429 doesn’t poison a snapshot.
- Output plumbing. Getting clean CSV/JSON into a warehouse or a Google Sheet, on a schedule, is plumbing you’d otherwise build.
If you’re already running a data platform, write the puller. If you want a scheduled, normalized feed without standing up infrastructure, the managed actor hands you flat tabular rows and a scheduler out of the box.
Schema design for downstream use
A unified per-pair record that handles all three categories:
{
"symbol": "BTCUSDT",
"category": "linear",
"last_price": 63420.5,
"change_24h_pct": 2.13,
"high_24h": 64100.0,
"low_24h": 61800.0,
"volume_24h": 48210.5,
"turnover_24h": 3052100000.0,
"bid_price": 63420.0,
"ask_price": 63421.0,
"funding_rate": 0.0001,
"open_interest": 51230.7,
"timestamp": "2026-05-22T12:00:00Z"
}
Schema choices worth making:
- Keep
categoryon every row. BTCUSDT exists in both spot and linear; without the category you can’t join correctly. - Make
funding_rateandopen_interestnullable. Spot rows have no funding — null is correct, zero is a lie. - Store numbers as numbers. Don’t carry the API’s strings into your warehouse.
- Always store the
timestamp. Funding and OI move continuously; a snapshot is only meaningful with the time it was valid. - Distinguish
volume_24h(base) fromturnover_24h(quote). Mixing them up is the most common analytics bug here.
Typical use cases
- Funding-rate arbitrage monitoring — track funding across Bybit perps (and against other venues) to find carry opportunities.
- Algorithmic / quant signals — feed momentum, mean-reversion or grid strategies with full-market price and funding snapshots.
- Cross-exchange arbitrage — combine with other exchange market scrapers to spot price and funding dislocations.
- Derivatives research — track funding-rate distribution and open-interest dynamics across the whole market.
- Portfolio dashboards — blend spot valuations with futures funding and OI exposure.
- Backtesting archives — scheduled snapshots build the historical dataset most public APIs won’t give you.
- Tax and accounting — periodic cost-basis snapshots for spot and futures positions.
- Upstream data products — a clean, normalized feed for resellers and indexer pipelines.
Cost math
Pricing is per dataset item — one row per pair. A full-market snapshot across all three categories is a few thousand rows; scheduling it every fifteen minutes is a few thousand rows per run, many times a day. Because each run is three API calls and finishes in seconds, the compute cost is negligible and you pay essentially for the rows you keep.
Self-hosting is cheap too — the API is free — but you’re maintaining the puller, the normalizer, the backoff logic, the scheduler and the export plumbing. For a recurring normalized feed, the managed actor removes all of that for the price of the rows.
Common pitfalls
- Treating the three categories as one shape. They aren’t. Normalize, or your funding column will be garbage for spot rows.
- Leaving numbers as strings. The raw API returns strings; carry them downstream and every aggregation breaks silently.
- Confusing volume and turnover. Base-asset volume and quote-currency turnover are different numbers. Label them clearly.
- Forgetting inverse units differ. Coin-margined (inverse) contracts report turnover and OI in different units than USDT-margined linear. Don’t sum across them blindly.
- Over-frequent snapshots without backoff. Hitting the API too hard without retry/backoff earns 429s and gaps in your archive.
- Assuming spot has funding. It doesn’t. Null, not zero.
Wrapping up
Bybit market data is easy to reach — it’s a clean public v5 API — but the value is in normalizing three category shapes into one typed, flat table, on a schedule, without rate-limit gaps. If you run a data platform, the puller is a quick write. If you want a scheduled, normalized snapshot of the entire Bybit market without building and babysitting the plumbing, use a managed actor that does the three-call merge for you.
▶ Open the Bybit Market Scraper on Apify — unified spot + linear + inverse snapshot with funding rate and open interest, normalized to flat rows. Schedule it for a fresh feed. Priced per row. Start on Apify’s free monthly credit.
Related guides
App Store Data API Alternative: ASO Metadata Beyond iTunes
Apple's iTunes Search and Lookup API is rate-limited and thin. Here's an App Store data API alternative that returns full reviews, rankings, and keyword signals for ASO.
Binance Market Data Without API Keys: Spot Prices and Funding in 2026
How to pull Binance spot prices, order books and funding data without API keys — using the public REST surface, its weight limits and region blocks explained.
CoinGecko API Alternative: Exchange Data Without Rate-Limit Pain
A CoinGecko API alternative for exchange and market data — why the free Demo tier's ~30 calls/min and Pro-gated fields force you to the public pages instead.