Getting Bitcoin Data: Core RPC vs Blockbook vs Hosted Address APIs

Developers coming to Bitcoin from Ethereum hit the same wall within an hour. On Ethereum, eth_getBalance(address) just works. On Bitcoin, you spin up a node, start calling JSON-RPC, and then try to answer "what's the balance of this address?" — and discover that Bitcoin Core simply can't tell you. There's no getbalanceofaddress. This isn't a missing feature; it's a consequence of how Bitcoin is built, and it shapes every decision about how you source Bitcoin data. This post covers the gap and the three ways providers fill it.

Why Core RPC can't answer address questions

Bitcoin is a UTXO chain: there's no global map of address → balance. The ledger is a pile of unspent transaction outputs, and an "address balance" is just the sum of the UTXOs currently locked to that address — something nobody maintains as an index unless they choose to build one.

Bitcoin Core's wallet is also node-centric: getbalance reports the balance of the wallet the node manages, not any address you ask about. Even with -txindex enabled — which lets you fetch any transaction by hash with getrawtransaction — there's still no way to ask "give me every transaction touching this address" or "list this address's UTXOs." Core indexes transactions, not addresses. (The same is true for Litecoin and Dogecoin, which are Bitcoin forks — see the Litecoin RPC guide for the UTXO-specific version of this.)

So the moment your app needs to show a user their balance, list their coins to build a transaction, or display an address's history, raw Core RPC leaves you stranded. You need an address index layered on top.

The three ways to get the data

1. Raw Bitcoin Core JSON-RPC

What it's genuinely great at: everything that isn't an address query.

curl -s -X POST "https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getblockchaininfo","params":[]}'
# → { "chain":"main", "blocks":963140, "pruned":false, ... }

Blocks, transactions, mempool inspection, fee estimation, and — critically — broadcasting signed transactions all live here. If you're building a node-adjacent service, Core RPC is the foundation. It just can't do addresses.

2. Blockbook (the Trezor address indexer)

Blockbook runs alongside bitcoind, reads the chain, and builds the address index Core lacks. It exposes a REST (and WebSocket) API for exactly the queries you were missing:

curl -s "https://rpc.swiftnodes.io/blockbook/btc/api/v2/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX?details=basic&key=YOUR_API_KEY"
# → { "address":"12c6DSiU...", "balance":"5135273240", "txs":231, ... }   (balance in satoshis)

That's a balance (in satoshis — ~51.35 BTC here), transaction count, and with other endpoints: UTXO lists, full transaction history, and xpub queries that derive and scan an entire HD wallet from an extended public key. Blockbook is what SwiftNodes runs for BTC, LTC, and DOGE, so the same /blockbook/<chain>/api/v2/... shape works across all three.

3. Esplora / electrs (the Electrum-family indexers)

Blockstream's Esplora (and the electrs server behind it) are the other common address-index layer. They solve the same problem with a different API shape — Esplora has its own REST conventions, and the Electrum protocol underpins most light wallets. If you're already in the Electrum ecosystem, this is the natural fit; the trade-off is a different API to learn than Blockbook's.

What each actually gives you

The pattern is clear: you want Core RPC for the node operations and an address indexer for everything address-shaped. Neither replaces the other.

The provider gotcha

Here's where choosing a provider gets tricky. Most RPC providers are EVM-first — Bitcoin is an afterthought, and "Bitcoin support" often means raw Core RPC only. You can broadcast and read blocks, but the instant you need an address balance you're on your own, because they never built the index.

So the real question to ask any Bitcoin RPC provider isn't "do you support Bitcoin?" — it's "do you offer an address / UTXO / xpub API, or just node RPC?" The providers that take UTXO seriously (SwiftNodes among them) pair Core JSON-RPC with an address indexer like Blockbook. The ones that don't will quietly leave you to run your own.

And running your own is not trivial. A full archival bitcoind plus a Blockbook index is well over 2 TB of fast storage per chain, and the index build is memory-hungry and slow — the kind of thing that's genuinely cheaper to rent than to operate, the same calculus as self-hosted node vs RPC provider, with the added twist that you're maintaining two systems (node + indexer) instead of one. Address queries also need unpruned history, so a pruned node won't do — see full node vs archive node.

What to check when picking a Bitcoin RPC provider

1. Core JSON-RPC for broadcasting, fees, blocks, and mempool.
2. An address API — balance, UTXOs, history, and ideally xpub. This is the piece most providers skip.
3. The UTXO chains you actually need. Many providers do BTC only; if you need Litecoin or Dogecoin too, confirm it. (SwiftNodes runs all three.)
4. Archive, not pruned — address history requires full chain data.
5. Predictable pricing — the same flat-rate-vs-metered question that applies to EVM RPC applies here.

The takeaway

Bitcoin Core RPC and an address indexer are two halves of a whole: Core handles blocks, mempool, fees, and broadcasting; Blockbook (or Esplora) handles anything keyed on an address. Raw node access alone can't show a user their balance — and that's the exact spot where a lot of "Bitcoin-supported" providers stop. Pick one that gives you both.

SwiftNodes serves both halves for BTC, LTC, and DOGE behind one key — Core JSON-RPC at /rpc/<chain> and the Blockbook address API at /blockbook/<chain>/api/v2/..., flat-rate with no per-request metering. Sign up for a free key and try an address query against https://rpc.swiftnodes.io/blockbook/btc/api/v2/address/<address>?key=YOUR_API_KEY.