OHLCV

Every card in Crypto Market Data APIs is read for the same thing first — does it have candles, and how far back. Both halves of that question are worth less than they look, because a candle is not something a venue records. It is something somebody computes, and this catalogue's own cards show the computation coming out differently at nearly every stop.

How it works

A matching engine emits trades. Nothing in it emits a candle. Somewhere between the print and the chart, a process buckets those trades by time and reduces each bucket to a handful of numbers, and in doing so it makes four decisions that the five letters do not record.

Where the bucket starts. For anything shorter than an hour this is uncontroversial. For a day, a week or a month it is a choice, and Binance exposes it as a parameter — the klines endpoint takes an optional timeZone from -12 hours to +14 hours, defaults to UTC, and documents that kline intervals are then interpreted in that timezone while startTime and endTime are always interpreted in UTC regardless. A daily bar is therefore a claim about a calendar as much as about a market, and two clients hitting the same endpoint for the same pair can hold different days.

Which prints go in. A single venue's candle is that venue's own tape. An aggregator's candle is a composite whose membership and weighting are a methodology — the subject of where the bitcoin price actually comes from, and not a detail that survives into a column labelled close.

What comes out. OHLCV is not even a fixed tuple. A Binance kline is a 12-element array — open time, the four prices, volume, close time, quote asset volume, number of trades, taker buy base volume, taker buy quote volume, and one ignored field. A Kraken OHLC row is eight elements, and two of them are things Binance does not put in the same place — a volume-weighted average price and a trade count. Code written against one shape and pointed at the other does not fail; it reads the wrong column.

Whether the last bar is finished. Kraken documents that the last entry in its array is for the current, not-yet-committed timeframe and will always be present regardless of what you pass as since. That is the honest behaviour and it is the one most likely to be stored as though it were final.

What the cards here actually record

A candle endpoint is not a given. The DEX Screener card records the absence explicitly — the published REST surface has no OHLCV endpoint, only a pair's current state and its 5-minute to 24-hour deltas. GeckoTerminal publishes one over comparable pools, at daily, 12, 4 and 1-hour and 15, 5 and 1-minute aggregates, capped at 1,000 rows a call and paging backwards.

The interval you can ask for is a product decision. CoinGecko's OHLC endpoint picks the candle body from the range you request, 30 minutes at the finest, and sells the explicit interval parameter with a subscription. Tardis.dev sells derived candles at ten minutes or longer as a distinct thing from raw data. Binance offers a one-second bar; Kraken's shortest is a minute.

Reading history is paced and metered. OKX returns only the latest 1,440 entries from its live candles endpoint, so any chart longer than a day is a join against a second endpoint with its own rate limit and an off-by-one at the seam. CoinAPI bills a call that uses limit at one credit per 100 data points, so pulling 10,000 bars costs 100 credits rather than one. Kraken returns at most 720 candles and documents that older data cannot be retrieved from that endpoint at all.

Depth differs by years, not months. Amberdata records OHLCV back to 18 August 2011 on Bitstamp; Kaiko puts trades and OHLCV at 2010 on REST. Those are reconstructions of venues that in some cases no longer exist, which is a different product from a live venue's own tape.

Why it matters here

The field on a card answers whether candles exist. The question underneath is whose.

A backtest run on aggregated candles inherits every one of the four decisions above without recording that it did — which bucket boundary, which venues, which volume convention, and whether the final bar had closed. That inheritance sits alongside the fill rule and the cost model in what a crypto backtest silently assumes, and it is the one an engine cannot warn you about, because by the time the data reaches the engine the choices have already been made and discarded.

The practical failures are dull and repeatable. A daily strategy is re-run against a second vendor and every bar is shifted, because one publisher closes the day at UTC and the other does not. A volume filter passes on one feed and fails on another, because one counts base and the other counts quote. A live signal fires on a bar that had four seconds left to run. A reconciliation between an aggregator's minute candles and an exchange's own is opened on the assumption that one side is broken, and closed weeks later with neither side broken.

What to ask a vendor, in order — which venues' prints go into a bar, where the daily boundary sits and whether it moves, whether the newest bar is closed or running, whether volume is base or quote, how many bars come back per call, and how that call is metered. On the free and public feeds in this catalogue, all six are answerable from the documentation in about ten minutes, and none of them is answerable from the word OHLCV.