How to pull OHLCV candles from a crypto exchange

The short way

CCXT and fetchOHLCV. It is an MIT-licensed client library, it normalises 104 exchange APIs to one set of method names, and it is what several of the bots and backtesters in this catalogue already reach exchanges through — Freqtrade fetches its candles that way.

import ccxt

exchange = ccxt.binance()
bars = exchange.fetch_ohlcv('BTC/USDT', timeframe='1m', limit=1000)
print(bars[0])  # [timestamp_ms, open, high, low, close, volume]

No key, no account, no vendor in the path: it is a client-side library, so your process talks to the exchange directly. Swap ccxt.binance() for ccxt.okx() and the rest of the file is unchanged, which is the whole reason to start here rather than with an HTTP client and one venue's parameter names.

For a backfill, page backwards with the since parameter and keep the venue's per-call ceiling in mind: Binance returns at most 1,000 klines per call and defaults to 500. Anything longer than a few thousand bars is a loop with a sleep in it, not one request.

What the options are

One library, many venues. CCXT, as above. Use it when the venue is a parameter rather than a decision — a screener, a backtest across exchanges, anything where you will want a second venue within a month.

The venue's own endpoint. Binance's market data API is free, unkeyed and deeper than the library exposes: daily BTCUSDT klines from 17 August 2017, and underneath the REST surface a plain HTTP directory of zipped monthly and daily CSV dumps with no account and no rate limit beyond the ordinary. For a multi-year backfill of one venue, downloading the archive beats paging an API by an order of magnitude. Go direct when you need one exchange, or when you need a field the unified surface does not carry.

An aggregate across venues. The CoinGecko API answers a different question — what did this asset do, rather than what did this order book do. Granularity is chosen for you from the range you request, the Demo plan is capped at 365 days of history and the Basic plan at two years, and minute-level granularity is an enterprise plan. Use it when the asset is the subject and the venue is noise.

One symbol scheme over everything. CoinAPI exists for the case where reconciling BTCUSDT, BTC-USD and XBT/USD across 400+ venues is the actual work. Watch the meter: a credit is one call except where the limit parameter is used, and then every 100 data points counts as one, so 10,000 bars in a single call is 100 credits.

The prints themselves. Tardis.dev records exchange websocket feeds and replays the raw messages, so you can build the candle you actually want instead of accepting one. Its own aggregated candles start at ten minutes; below that you are working from ticks, which is the point of buying it.

Where this breaks

The rate limit is not a number of requests. Binance's spot budget is 6,000 weight a minute counted per IP, not per key, and the weights are not uniform: a klines call costs 2, a trades call costs 25, an order book costs 5 at depth 100 and 250 at depth 5,000. Six thousand weight is three thousand candle pulls or twenty-four deep book snapshots. Per-IP is the part that decides your architecture — a second key does not buy a second budget, and a serverless deployment shares one with strangers. The families of limit in use across this catalogue, and what each one is really counting, are in rate limit.

An exchange's own endpoint and a normalising library are not the same product. The library gives you one method and one returned shape; what it cannot give you is a venue's non-standard extras, and it cannot give you history the venue does not serve. CCXT ships no data of its own — "the history you can fetch is the history that venue's API serves and no deeper", with no storage layer and no cross-venue backfill. And the pacing is client-side, computed against constants compiled into each exchange class rather than against anything the venue reports back. When a venue changes a limit, the library finds out when you get banned.

There is also a per-venue trap the unified surface hides. OKX's regular candles endpoint returns only the latest 1,440 entries — on a one-minute bar, a single day — and everything older comes from a second endpoint, history-candles, with a different rate limit and 300 results per request. Kraken's is blunter: up to 720 of the most recent entries, and the documentation says older data cannot be retrieved regardless of what you pass as since.

A one-minute candle is not a one-minute candle. Two feeds labelled the same way for the same pair are routinely different series, and the reasons are all publisher's choices: which trades went into the bucket, where the boundary falls, whether late or corrected prints were folded back in, whether volume is counted in the base asset or the quote. Binance's klines endpoint takes a timeZone parameter that shifts the interval boundaries while leaving startTime and endTime in UTC — so the same request with one parameter changed returns differently-bucketed bars with identically-formatted timestamps. Both series are correct. OHLCV is the longer version of why.

The last bar is open. Kraken documents that the final entry is the current, not-yet-committed timeframe and is always present. Most venues do the same and do not mention it. If your loader does not drop the newest bar, your store will hold two different rows for one timestamp and your backtest will read a close that had not happened yet.

Free to fetch is not free to publish. Every public endpoint here has a redistribution clause behind it, and the ones that are easy to read are the strictest: Binance's dataset terms bind you on downloading, caching or querying, and bar hosting or commercially exploiting the data or any derivative feed. Personal, internal research is granted everywhere. What exchange API terms actually let you do is the whole of it, and redistribution is the word to know before you ask a vendor for a quote.

If you outgrow this

Three exits, and they are different products rather than bigger plans.

If the problem is depth of history, the flat-file archives come first — free, and enough for most backtests on a major venue — and Kaiko is the paid end, with tick trades and OHLCV back to 2010 at granularities from one second to one day, on a price quoted per instrument count and never published.

If the problem is comparability across venues, no amount of candle-pulling fixes it, because the disagreement is in the definitions rather than in the data. That is a reference-rate purchase: Coin Metrics for the institutional version, where the Bitcoin price comes from for why one number is not simply available.

If the problem is that a candle is the wrong object — you are testing anything that touches the book, the spread or the queue — stop aggregating and buy the prints. Tardis.dev records the raw websocket messages; what a crypto backtest assumes is the argument for when that matters.