BitcoinDatabase.com

Query the chain · Node API

Bitcoin node API and RPC access without running a full node

A Bitcoin node API gives you the data a full node holds without the cost of running one. Bitcoin Core needs hundreds of gigabytes of disk, days to sync from the genesis block, and constant reconciliation as new blocks confirm. BitcoinDatabase keeps that node indexed for you and exposes the same information over a clean REST endpoint: fetch a block by height or hash, pull a raw transaction, read an address balance to the satoshi, and check the mempool.

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 ...

If you already speak JSON-RPC, the mapping is direct. Calls like getblock, getrawtransaction, getblockcount and getmempoolinfo map to REST endpoints that return typed JSON, so you can retire your own node or run us as a redundant backend. Start with an API key in minutes and pay for what you query. This is informational on-chain data only, not financial 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 Node API

A node without the node

We run and reconcile Bitcoin Core for you, so you skip the disk, the multi-day initial sync and the DevOps of keeping a full node at the chain tip.

JSON-RPC calls you know

getblock, getrawtransaction, getblockcount and getmempoolinfo map to REST endpoints that return clean, typed JSON, so porting existing node code is mostly a URL change.

Same data, three ways

The indexed chain behind the node API is also queryable in SQL and dashboards, so analysts and apps read from one authoritative dataset.

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 any block by height or hash with full transactions
  • Pull raw and decoded transactions with inputs and outputs
  • Read address balances and history to the satoshi
  • Check mempool size, fees and unconfirmed transactions
  • Replace or back up your own node with one API key
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 Node API

It is a fully-indexed copy of the chain served over a REST API. We run and reconcile the node infrastructure so you do not have to, then expose blocks, transactions, balances and mempool state through endpoints that return typed JSON. You get node-grade data without syncing Bitcoin Core yourself.
For read queries, yes. Common calls like getblock, getrawtransaction, getblockcount and getmempoolinfo have direct REST equivalents that return the same fields. Broadcasting your own transactions still needs your own node or wallet. This is informational on-chain data, not financial advice.
No, and this is the single most useful thing to know before choosing a node provider. We called three public Bitcoin RPC endpoints on 1 September 2026 and getbalance, listunspent, getreceivedbyaddress and getaddressinfo failed on every one of them. Bitcoin Core keeps unspent outputs keyed by transaction id and output index, with no address index, so a node genuinely has nothing to look up when you hand it an address.
It is the one Core method that could work, using an addr() descriptor to sweep the whole UTXO set, and no shared provider will let you run it. Measured on 1 September 2026, QuickNode refuses it with HTTP 400 and error -32604, and PublicNode returned nothing inside a 12 second timeout. Even if it ran it would only see currently unspent outputs, so it cannot give you history, a first-seen date, or a balance as of a past block.
There is no shared contract, which is what breaks provider-agnostic code. Across two providers we recorded four different signals for the same refusal: -32601 Method not found inside an HTTP 200 body, -32604 with HTTP 400, -32701 with HTTP 501, and a bare HTTP 429 with no JSON-RPC error object. Handle unavailability as a set of cases and assert on the shape of the result rather than the absence of an error.
Chain and block reads are universally available: getblockcount, getblock, getblockstats, getrawtransaction, estimatesmartfee, getmempoolinfo and getblocktemplate all answered on the endpoints we tested. Wallet methods are universally blocked. Node introspection varies: getpeerinfo, getnettotals and getmemoryinfo answered on QuickNode and were refused on PublicNode.
Measured from one US machine on 1 September 2026, a getblockcount round trip had a median of 0.043 seconds against PublicNode and 0.144 seconds against QuickNode over seven calls each. Treat those as an order of magnitude rather than a benchmark. What matters more for most workloads is how many round trips your question needs, because one indexed address query replaces the thousands of node calls it would take to rebuild the same answer.
If you broadcast transactions, yes. Relaying, mempool acceptance testing and fee estimation against live policy all belong to node infrastructure, and we are read-only. If your product only reads the chain, and especially if its queries start with an address, an xpub or a date range, an indexed API removes both the node and the address index you would otherwise build beside it.
Our own costing put a production-grade unpruned node in AWS at roughly $390 to $430 a month. The two public nodes we probed on 1 September 2026 were each carrying about 872 GB of chain, and that is before any address index is layered on top. The larger cost is usually engineering time spent keeping an indexer from silently falling behind the tip.
Yes, and it is a common pattern. Point your read path at the API and keep your node for the write path, or fail over to the API when your node is resyncing or behind. Because the index is reconciled against the chain rather than mirrored from another provider, a disagreement between the two is a signal worth investigating rather than noise.

Explore more

More ways to query Bitcoin with BitcoinDatabase

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