Bitcoin RPC & Blockbook API

Bitcoin works differently from every EVM chain, so its API surface is different too. There is no eth_getBalance, no accounts, no gas, and no smart contracts. Instead you get two complementary APIs behind one endpoint: the Bitcoin Core JSON-RPC for chain data and broadcasting, and the Blockbook REST API for address, UTXO, and xpub queries that Bitcoin Core alone cannot answer. This guide covers both.

Two APIs, one endpoint

Bitcoin Core is a full node, but it has no address index— it can tell you about a transaction if you know its ID, but it cannot answer “what is this address’s balance?” or “list this wallet’s history.” That is what Blockbook(Trezor’s indexer) is for. SwiftNodes runs Blockbook alongside the node and exposes both:

Connecting

Both APIs take your API key as ?key=YOUR_API_KEY. Core JSON-RPC is a single POST endpoint; Blockbook is a REST API where the path selects the query.

# Bitcoin Core JSON-RPC — current block height
curl -s -X POST https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"getblockcount","params":[],"id":1}'
# -> {"jsonrpc":"2.0","result":956754,"id":1}

# Blockbook REST — address balance & history
curl -s "https://rpc.swiftnodes.io/blockbook/btc/api/v2/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?key=YOUR_API_KEY"
# -> {"address":"1A1z…","balance":"10723293944","txs":63427, …}

The UTXO model in 60 seconds

Bitcoin has no account balances. Coins exist as unspent transaction outputs (UTXOs)— discrete chunks locked to a script (usually an address). A “balance” is just the sum of an address’s UTXOs. To spend, a transaction consumes whole UTXOs as inputs and creates new outputs (the payment, plus a change output back to yourself). This is why you almost always need the UTXO list before you can build a transaction — and why getbalance-style calls live in the Blockbook index, not in Bitcoin Core.

Bitcoin Core JSON-RPC essentials

Standard Bitcoin Core methods, POSTed to /rpc/btc. The ones you’ll actually use:

# Fee rate for confirmation within ~6 blocks
curl -s -X POST https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"estimatesmartfee","params":[6],"id":1}'
# -> {"result":{"feerate":0.00000462,"blocks":6},…}   (feerate is BTC/kvB)

# Broadcast a signed raw transaction
curl -s -X POST https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"sendrawtransaction","params":["0200000001…"],"id":1}'

Blockbook: address, UTXO & xpub API

This is the part Bitcoin Core can’t give you. All routes are GET under /blockbook/btc/api/v2/:

# Spendable UTXOs for an address (what you need to build a tx)
curl -s "https://rpc.swiftnodes.io/blockbook/btc/api/v2/utxo/bc1q…?key=YOUR_API_KEY"
# -> [{"txid":"f69b…","vout":0,"value":"546","confirmations":9}, …]

# Whole-wallet view from an extended public key
curl -s "https://rpc.swiftnodes.io/blockbook/btc/api/v2/xpub/zpub…?details=txs&key=YOUR_API_KEY"

Building & broadcasting a transaction

There is no server-side wallet here — you build and sign transactions client-side (keys never leave your environment), then broadcast. The typical flow:

1. Get UTXOs for the sending address — Blockbook /utxo/{addr}.
2. Estimate the fee — Core estimatesmartfee or Blockbook /estimatefee/6; Bitcoin fees are sat/vB (satoshis per virtual byte), multiplied by the transaction’s vsize.
3. Build & sign locally with a library like bitcoinjs-lib, selecting inputs and adding a change output.
4. Broadcast — Core sendrawtransaction or Blockbook /sendtx/{hex}.
5. Track — poll Blockbook /tx/{txid} and watch confirmations climb.

Fees, confirmations, and finality

Bitcoin fees are paid per virtual byte, not per unit of computation — a transaction’s cost is its fee rate (sat/vB) times its size, and the difference between inputs and outputs is the fee (there is no separate fee field). Finality is probabilistic: a transaction gets safer with each block mined on top. One confirmation is fine for small amounts; six confirmations (~60 minutes) is the common bar for high-value settlement. Blocks target ~10 minutes, so plan for latency very different from an EVM chain.

How it differs from EVM chains

https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY            # Core JSON-RPC
https://rpc.swiftnodes.io/blockbook/btc/api/v2/…?key=YOUR_API_KEY   # Blockbook REST