BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API On-chain data Transaction API Bitcoin data API Wallet tracker On-chain metrics Rich list Address balance API Query with SQL Crypto AML API UTXO data Blockchain API Flow analysis Node API Webhook API Price API Transaction monitoring Mempool API RPC API xpub balance API See all →
Glassnode alternative Dune alternative Blockchair alternative Chainalysis alternative BlockCypher alternative Chainstack alternative Blockchain.com API alternative Mempool.space alternative CoinAPI alternative TRM Labs alternative Whale Alert alternative CoinGecko alternative CoinMarketCap alternative Blockdaemon alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative
Docs Pricing Blog Contact

Query the chain · Balance history

Bitcoin address balance history API at any block height or date

A Bitcoin address balance history API answers what a block explorer will not: not what an address holds today, but what it held on a given date. Pass an address with a block height or timestamp and get the balance as it stood then.

or try it below ↓

REST API · SQL · dashboards · indexed from genesis

Query Console
btc
try:

Hit Run to query the fully-indexed Bitcoin blockchain.

BTC

30-day trend

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Querying the indexed Bitcoin blockchain ...

Explorers are built around the present. Ask a public explorer API for an address and you get its current aggregates back: total funded, total spent, transaction count, and the balance those imply right now. Add a height parameter to the request and the response does not change, because the endpoint has no concept of a point in time. We tested that on 4 August 2026 against two of the most widely used public endpoints, and both returned byte-identical answers with and without a height filter. A third, popular enough that it is still the top recommendation in years-old forum threads, answered a balance request scoped to an earlier block with zeroes across every field, for an address that demonstrably held coins at that height. Silent zeroes are worse than an error, because a script accepts them.

The reason is structural rather than sloppy. A balance is not stored anywhere on the Bitcoin blockchain. It is the sum of the unspent outputs pointing at an address, and a node keeps exactly one version of that set: the current one. To know what an address held at block 500,000 you have to replay every output it ever received and every one it spent, keep the ones confirmed at or before that height, and add them up. That is a full-history computation, which is precisely what an indexed chain is for. Here it is a lookup: every input and output since the 2009 genesis block is already indexed with its confirming block, so a balance at any height in the chain's history comes back as fast as the current one.

Ask for a single point in time, or ask for the whole line. A balance history request returns the running balance across a date range, one row per day or per movement, with the transaction that caused each change. That is the shape auditors, tax preparers and fund administrators actually need, because a period-end holding is meaningless to them without the movements that produced it. Every figure is paired with the block height that fixes it, so anyone can reproduce your number by repeating the query rather than taking your word for it. Point-in-time market data is available on the same timeline if you need the USD value on that date as well as the BTC amount. This is informational on-chain data, not tax, accounting, financial or legal advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

Indexed from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Balance history

Any block, any date

Pin a balance to a block height or a timestamp and get what the address held at that exact point, computed from every output it had received and spent by then. The same request works for block 100,000 and for last Tuesday.

The whole line, not one dot

Return a running balance across a date range with one row per day or per movement, each tied to the transaction and block that changed it. A period-end figure arrives with the history that produced it, which is what an audit trail means.

Reproducible by anyone

Every balance comes back with the block height it was measured at. Give an auditor the address and the height and they can rerun the query and land on the same satoshi, which is the difference between a number and evidence.

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.

  • Query an address balance at any past block height
  • Query a balance by calendar date or timestamp
  • Return a running balance timeline for a date range
  • Reconstruct year-end holdings for tax and audit files
  • Pin reserve snapshots to a stated block height
  • Attach the USD value on that date to each BTC figure
  • Run point-in-time balances across a whole address list
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 Balance history

Yes, though not from an ordinary block explorer. The balance is reconstructed by taking every output the address received and every one it spent, keeping only those confirmed at or before that date, and summing what is left. An indexed chain does that computation for you and returns the figure directly, along with the block height that fixes it.
Convert the date to a block height, or let the API do it, then request the balance as of that height. Dates are ambiguous on their own because blocks arrive roughly every ten minutes and time zones shift the boundary, so a height is the precise version of the same question and the one an auditor can check.
Most cannot. Explorer APIs return current aggregates such as total received, total sent and the resulting balance, and adding a height parameter to the request typically changes nothing. The transaction list is there, so the history is technically visible, but turning it into a balance on a given date is arithmetic you have to do yourself.
Send the address and the height together in one request. The result is the sum of outputs paid to that address in blocks up to and including that height, minus the ones already spent by then. Because the chain is indexed by confirming block, the answer for an old height costs the same as the answer for the chain tip.
Transaction history is the list of movements in and out of an address. Balance history is the running total those movements produce over time. An explorer gives you the first, and most accounting, tax and audit work needs the second, which means someone has to fold the transactions into a cumulative series.
Because a balance is an indexer output, not a protocol field, and indexers make different choices. The best-known case is the genesis block coinbase, which Bitcoin Core never adds to the UTXO set, so explorers built on it exclude that 50 BTC while others count it. Whichever convention a provider uses, historical answers are only comparable if the convention is stated.
No, though it is one route. A node with a transaction index holds the raw data, but it stores only the current UTXO set, so you would still build the replay logic and the storage to compute past balances. Reading a chain that is already indexed by confirming block skips both the sync and the indexer.
Yes. Pass the address list with a single height and you get one point-in-time row per address, which is how reserve snapshots and year-end holdings for a treasury are usually produced. Extended public keys work the same way, expanding to their derived addresses before the balances are totaled.
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

BTC address balance API

Get exact balances and UTXOs for any address, in batches.

Learn more

Bitcoin address lookup

Look up any Bitcoin address: balance, full history and UTXOs in one query.

Learn more

Bitcoin API

Query addresses, transactions and balances across the whole indexed chain in one call.

Learn more

xpub balance API

Derive an HD wallet's addresses from its xpub and total the balance to the satoshi.

Learn more

Bitcoin active addresses

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

Learn more
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, indexed from the genesis block. Informational on-chain data only, not financial advice.

See pricing

Indexed from genesis · REST · SQL · dashboards · addresses, transactions, UTXOs, metrics