Bitcoin API documentation

Authentication

Authenticate every request by passing your secret key in the Authorization header as a bearer token. Keep your key secret, on a server and out of client-side code. You get a key when you create an account.

GET /v1/address/{addr}

Look up a single address. Returns its confirmed balance to the satoshi, transaction count, first and last seen, and any entity label such as exchange, miner or service.

Core endpoints

GET /v1/tx/{txid}

Resolve a transaction by its hash. Returns the full set of inputs and outputs, the fee, the block it was mined in and its current confirmation count. Unconfirmed transactions in the mempool come back with a confirmations value of zero.

Address screening and the screening book

On the Enterprise plan, GET /v1/screen/{addr} checks an address against every entry of the published OFAC SDN list, then reads its transactions to find direct counterparties (who paid it and whom it paid) and near counterparties (who funded the coins it received). Each counterparty is matched against the list and against entity labels. The answer carries a risk signal (low, medium, high or severe), the reasons, every finding with the transaction ids behind it, the list version it was made against, the block height, and how much of the history was read. A screening costs 10 credits.

Add addresses to your book with POST /v1/screening/book and a JSON body {"addresses": [...]}. Each new address is matched against the current list at once, and every entry is rescreened automatically when a new list version arrives against the address and the counterparties its last screening read, so a new designation among them shows up in GET /v1/screening/book?changed=1. Each entry says whether that screening read the full history (trace_complete); for a busy address it covers the newest transactions. A signal is context for your own compliance review, not a verdict on anyone.

SQL access

From the Growth plan and up, you can query the indexed chain with raw SQL. Write your own joins across addresses, transactions, blocks, UTXOs and metric tables, reproduce any dashboard number from the underlying rows, and export results in bulk. A SQL query costs more credits than a single REST lookup.

The schema tables you can query

SQL queries run against a normalized model of the chain. These are the core tables and the columns most queries reach for. Every row is derived from the indexed chain itself, so a query returns the same answer as recomputing it from raw blocks.

Two joins carry most analysis. inputs links to outputs on prev_txid and prev_vout, which is how you follow coins from where they were created to where they were spent. transactions links to blocks on block_height, which is how you put a timestamp on anything.

An unspent output is simply spent = false, so a balance is a sum over that filter and the UTXO set is a view rather than a separate product. Because script_type sits on every output, any query can be filtered or grouped by address type.

SQL query examples

Four worked queries against the tables above, covering the shapes people ask for most: a balance, a historical series, a flow trace and a cohort.

The same patterns extend to the rich list, exchange reserve totals over any address set you define, and historical series rebuilt from the rows rather than read off a chart.

Rate limits and credits

Each plan includes a monthly pool of API credits and a per-second request limit. Calls cost credits by type, so light lookups are cheap and heavier queries cost more. If you exceed your rate, the API returns 429 with a Retry-After header.

Documentation FAQ

Where to go next

The endpoints above are the primitives. Most work starts from a specific question, and these pages show the query shapes for the common ones: address lookup, address balances at scale, transaction data, SQL over the chain, on-chain metrics and the comparison of Bitcoin APIs if you are still choosing.