BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API Transaction API Bitcoin data API On-chain metrics Rich list Query with SQL Crypto AML API UTXO data Node API Webhook API Price API Transaction monitoring xpub balance API See all →
Glassnode alternative Blockchair alternative BlockCypher alternative Mempool.space alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative Alchemy alternative QuickNode alternative Hiro alternative Amberdata alternative Elliptic alternative Merkle Science alternative Coin Metrics alternative CoinGlass alternative Crypto APIs alternative Tatum alternative NOWNodes alternative GetBlock alternative Arkham Intelligence alternative Santiment alternative Nansen alternative Allium alternative Flipside alternative SonarX alternative GoldRush alternative Scorechain alternative AMLBot alternative
Docs Pricing Blog Contact Sign in

Query the chain · OHLC API

Bitcoin OHLC API for OHLCV candles and price history

GET /v1/price/ohlcv returns Bitcoin OHLCV candles at 1d and 1h from 18 August 2011, in JSON or CSV, with every day starting at 00:00 UTC.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

Every candle comes from one USD spot order book, never stitched from several venues, and is labeled by the start of its bucket. Each row carries time, timestamp, open, high, low, close, volume_btc and a closed flag, so the still-forming candle is never mistaken for a final one. One call returns up to 10,000 candles for 10 credits, which is more than a year of hourly data. The same series sits in SQL as the price_candles table, next to blocks, transactions, inputs and outputs, so you can join a day close to that day exchange inflows, active addresses or realized price in one query. This is informational market and on-chain data, not a trading signal or investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with OHLC API

Daily and hourly candles since 2011

Ask for interval=1d or interval=1h with from and to as a unix timestamp or an ISO date, and set limit up to 10,000. Days start at 00:00 UTC, so a daily close never shifts by 16 hours the way a UTC+8 exchange default does. Resample hourly rows to four hours or a week yourself from one consistent series.

Joined to the chain

Because candles and the indexed chain share one schema, you can join a day close to that day exchange flows, active addresses, realized price or supply in profit in a single SQL query, instead of reconciling two separate feeds.

Backfill and keep current

Fifteen years of daily candles fit in one call, and a year of hourly candles in another. The series refreshes twice an hour, and the closed flag tells you whether the latest candle is final. Your plan sets the history window: Developer reads one year back, Growth and above read back to August 2011.

Side by side

Which Bitcoin daily candle endpoints do not use a UTC day, tested 1 September 2026

We called 18 public daily-candle endpoints from one machine on 1 September 2026 and read the raw start timestamp of every candle rather than trusting its date label. Four of them do not return a UTC day at all: they start at 16:00 UTC, which is midnight in UTC+8. Every one of those four returns HTTP 200 and a column named close. Rows are the close for the UTC day of 30 August 2026, a fully closed day.

Endpoint and parameter Candle starts Close for 30 Aug 2026 Same date vs Binance 1d UTC-day option
Bitstamp btcusd, step=86400 00:00 UTC 77,701.70 top of band default
MEXC BTCUSDT, interval=1d 00:00 UTC 77,699.42 inside default
Gemini btcusd, 1day 00:00 UTC 77,698.53 inside default
KuCoin BTC-USDT, type=1day 00:00 UTC 77,687.50 inside default
Bitfinex tBTCUSD, trade:1D 00:00 UTC 77,684.00 inside default
Gate.io BTC_USDT, interval=1d 00:00 UTC 77,683.40 inside default
Binance BTCUSDT, interval=1d 00:00 UTC 77,682.00 reference row default
Kraken XBTUSD, interval=1440 00:00 UTC 77,681.60 inside default
Bitget BTCUSDT, granularity=1Dutc 00:00 UTC 77,681.00 inside this is the fix
OKX BTC-USDT, bar=1Dutc 00:00 UTC 77,677.70 inside this is the fix
Crypto.com BTC_USD, timeframe=1D 00:00 UTC 77,677.62 inside default
Bybit BTCUSDT, interval=D 00:00 UTC 77,676.70 inside default
Coinbase BTC-USD, granularity=86400 00:00 UTC 77,665.14 bottom of band default
HTX btcusdt, period=1dayutc 00:00 UTC 77,631.18 33.96 below the band this is the fix
OKX BTC-USDT, bar=1D 16:00 UTC 78,588.50 906.50 above (1.167%) yes, bar=1Dutc
BingX BTC-USDT, interval=1d 16:00 UTC 78,580.42 898.42 above (1.157%) none exists
Bitget BTCUSDT, granularity=1day 16:00 UTC 78,575.00 893.00 above (1.150%) yes, granularity=1Dutc
HTX btcusdt, period=1day 16:00 UTC 78,506.71 824.71 above (1.062%) yes, period=1dayutc

Thirteen of the fourteen UTC-aligned rows sit inside a band 36.56 USD wide, a spread of 4.7 basis points on a roughly 77,700 USD asset. So the four shifted rows are wrong by roughly 25 times the entire disagreement between every independent order book we could reach. The error also does not calibrate away, because it is a 16-hour phase shift rather than a level shift: on 31 August the same four rows flipped sign and sat 661.86 to 739.95 USD BELOW Binance. The spelling of the fix is inconsistent across venues, and Bitget rejects granularity=1dutc with HTTP 400 while accepting granularity=1Dutc. BingX has no UTC-day option at all: its error response enumerates 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w and 1M. HTX runs about 0.05 percent below the pack on both of its endpoints, which is a genuine venue difference rather than a boundary artifact.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Fetch OHLCV candles at daily and intraday intervals
  • Backfill full price history for a backtest or model
  • Join a day close to on-chain metrics in one SQL query
  • Resample candles to any timeframe you need
  • Read the latest candles over REST for live charts
GET /v1/address/{addr} query result
200 · JSON 
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about OHLC API

On BitcoinDatabase a candle request costs 10 credits and returns up to 10,000 candles. Developer at $49 a month includes 500,000 credits and reads one year of history; Growth at $199 a month reads back to 18 August 2011 and adds SQL. Yearly billing halves both prices.
It tells you whether the bucket has ended. The most recent daily or hourly candle is still forming, so its high, low, close and volume will change until the bucket closes. Rows with closed set to true are final. Filter on it before a backtest or a period-end report so a partial candle never slips in.
It returns OHLCV candles, the open, high, low, close and volume for each time bucket, at daily and intraday intervals across the full price history. You can pull the series over REST for a chart or model, or query it in SQL and join it to on-chain data like exchange flows and active addresses in the same call.
A price-only API gives you candles and nothing else. Because BitcoinDatabase holds the candles in the same schema as the fully-indexed chain, you can line each candle up against what happened on-chain that day, exchange inflows, realized price, supply in profit, in one query. This is informational market and on-chain data, not a trading signal.
Request the interval and date range you need and take the response as JSON or CSV, one row per candle with open, high, low, close and volume. For a backfill, pull the whole history in one export rather than paging a public endpoint thousands of times, then keep it current with a scheduled call for the most recent candles. The export is the same data the REST endpoint serves, so a backfill and a live feed cannot drift apart.
Yes. A year of hourly candles is roughly 8,760 rows, which is a single request rather than a paged crawl. Timestamps are UTC and each candle is labeled by the start of its bucket, so you can resample to four hour or daily buckets yourself without worrying about which edge the provider used.
Pull hourly candles in UTC, then bucket each hour into the Sydney, London or New York session window and filter to weekdays if you want to exclude weekend behavior. Because every timestamp is UTC rather than a local exchange time, the session boundaries stay fixed and daylight saving shifts are yours to apply deliberately. Range or log return per candle then aggregates cleanly by session. This is informational data, not trading advice.
OHLCV is OHLC plus the volume traded in that bucket. The distinction matters more than it sounds, because that volume is exchange trading volume, not value settled on the Bitcoin network. On-chain transaction volume is a separate series measuring coins moved between addresses, and the two routinely diverge.
Barely, once you align the day boundary. Across seven venues that all start the daily candle at 00:00 UTC, the close for 30 August 2026 spanned 36.56 USD on a roughly 77,700 USD asset, a spread of 4.7 basis points. Over three closed days the widest disagreement on any single field was 17.7 basis points, on the daily low.
Because OKX bar=1D starts its day at 16:00 UTC, midnight in UTC+8, so it covers a different 24 hours than a Binance 1d candle carrying the same date. Measured on 30 August 2026 the two closes sat 906.50 USD apart. Pass bar=1Dutc and OKX returns 77,677.70, inside the band every other venue agrees on. OKX is not alone: Bitget, HTX and BingX default to the same 16:00 boundary.
Not directly from the OHLC endpoint. Its bucket width is chosen by the days parameter, not by you: days=1 returns 30-minute buckets, days=7 and days=30 return 4-hour buckets, and days=90 and days=365 return 4-day buckets. No setting returns a one-day candle, so you have to resample it yourself.
If your strategy trades on one venue, use that venue own candles, because its wicks are the fills you would actually have got. If you are modelling the asset rather than a venue, use a consistent single source and never mix two. The failure that quietly ruins backtests is stitching sources with different day boundaries, not picking the wrong exchange.
Much less than most people expect at daily resolution. Measured on 1 September 2026 across seven UTC-aligned venues, daily opens and closes agreed to between 2.3 and 5.1 basis points. Highs and lows disagree more, up to 17.7 basis points, because a wick is one order book worst single fill rather than a consensus price.
Almost none at daily resolution. On the same exchange and the same UTC day of 30 August 2026, Binance BTCUSDT closed at 77,682.00 and BTCUSDC at 77,682.54, a difference of 54 cents. The quote asset is not a meaningful source of divergence in daily candles; the day boundary is.
Of 18 daily-candle endpoints we called on 1 September 2026, four start the day at 16:00 UTC rather than 00:00 UTC: OKX with bar=1D, Bitget with granularity=1day, HTX with period=1day and BingX with interval=1d. That is midnight in UTC+8. All four return HTTP 200 and a field named close, so nothing in the response tells you the window moved.
Each spells it differently. OKX takes bar=1Dutc, Bitget takes granularity=1Dutc, and HTX takes period=1dayutc. Bitget is case sensitive here and rejects granularity=1dutc with HTTP 400 while accepting granularity=1Dutc. BingX has no UTC-day option at all: its error response lists every interval it supports and no UTC variant appears, so a BingX daily candle has to be rebuilt from hourly data.
Much larger than any disagreement between exchanges. On the UTC day of 30 August 2026 the four shifted endpoints sat 824.71 to 906.50 USD above Binance under the same date string, roughly 1.06 to 1.17 percent, while 13 UTC-aligned endpoints agreed inside 36.56 USD. It is also not a constant you can subtract: on 31 August the same four flipped sign and came in 661.86 to 739.95 USD below Binance, because a 16-hour phase shift moves with the market rather than adding a fixed offset.
Close enough that it will not change a decision, once the day boundary matches. Fourteen UTC-aligned endpoints closed 30 August 2026 across a 70.52 USD range, and 13 of them inside 36.56 USD, which is 4.7 basis points. The single outlier was HTX, which runs roughly 0.05 percent below the pack on both its endpoints, a real venue difference rather than a labeling artifact.
No, and it is worth being direct about it. Perpetual futures prices, funding rates and open interest live on derivatives venues, not on the Bitcoin blockchain, so they are outside what an on-chain index can verify. What we can do is give you the chain-side series to join against perp data you source elsewhere, such as exchange flows, realized price and fees by hour.
Daily and hourly candles here start in August 2011. Bitcoin traded from 2010, but the earliest venues were thin and priced it very differently from each other, so treat the first years of any series with care before a backtest depends on them. Backfill once from a single source, then keep it current, instead of stitching several feeds together.
Read every Bitcoin API question

Explore more

More ways to query Bitcoin with BitcoinDatabase

Bitcoin historical data API

Full-depth history: every block, transaction and metric back to 2009.

Learn more

Bitcoin transaction volume

Raw, change-adjusted and entity-adjusted on-chain volume series from the indexed chain.

Learn more

Bitcoin active addresses

Daily active address counts, historical series and entity-adjusted numbers from the indexed chain.

Learn more

Query the Bitcoin blockchain with SQL

Write plain SQL against the whole indexed chain, no node, no ETL.

Learn more

Bitcoin address balance history API

What an address held on any past date, not just what it holds now.

Learn more

On-chain metrics

Active addresses, realized cap, SOPR, HODL waves and exchange flows.

Learn more

Buyer guides and measurements on this topic

Best Bitcoin OHLCV Data API for Backtesting and Quant Research We pulled the same Bitcoin daily candle from nine public sources in one minute. Seven venues agreed to within 36.56 USD, or 4.7 basis points. One para... Best Bitcoin API for Crypto Tax Software and Cost Basis Crypto tax software needs the USD value of every transaction at the moment it confirmed, and the Bitcoin chain does not contain it. On 8 September 202... Bitcoin Balance History API Providers for Auditors A Bitcoin balance history API fit for audit work returns integer satoshis at a named block for every address type. On 29 September 2026 BlockCypher ma...
See every use case See pricing Back to the Bitcoin API

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics