Best Bitcoin Address API for Wallet and Exchange Engineering Teams

Wallet and exchange teams pick an address API early, usually in a week when the real work is elsewhere, and then live with it for years. The choice looks simple because every provider answers the same question: given an address, what is the balance. The differences only surface later, at volume, in reconciliation, or the first time a customer deposits to a format your code did not expect.

What follows is a buyer's walk through the decisions that actually cost money, with behavior we tested ourselves rather than read off a features page. Every result carries the date it was checked.

What a wallet or exchange backend actually needs

Five requirements, ordered by how often they get discovered too late.

Script type on the address, not just the balance. Deposit crediting, fee estimation and cold storage sweeps all branch on whether an output is legacy, P2SH, native SegWit or Taproot. Spending a Taproot input costs a very different number of virtual bytes than spending a legacy one, so a fee estimator that does not know the type is guessing.

An unambiguous balance convention. Two providers can both be right and disagree, and if you reconcile against the wrong one you will chase a phantom discrepancy for a day. See below, because the example is worse than most people expect.

Batch lookups. An exchange watching a hundred thousand deposit addresses cannot make a hundred thousand sequential calls. Whether the API accepts many addresses per request changes your infrastructure, not just your latency.

Rate limits you can plan against. Published, documented limits beat generous but undisclosed ones, because you can only build backpressure against a number you know.

History, not just the current tip. Support tickets are about last March. If the API only answers about now, every dispute becomes an archival project.

Does any Bitcoin address API return the script type?

We tested this directly. On 22 August 2026 we asked four public APIs about a Taproot address, bc1p26jgntm23d83wlwayj3535dqcmvmt3hec9w3mfn4l9qr6syn0kpsl94y4k, which held exactly 10 BTC from a single funding transaction and had never spent.

The type is not missing from the chain, only from the address view. Esplora does expose scriptpubkey_type on every output of a transaction, which is how we measured the numbers further down. So the type is reachable, just not where a wallet backend wants it: learning what format an address uses means fetching a transaction that touches it, or parsing the address string yourself and maintaining that parser as new output types appear.

For a single lookup that is a minor annoyance. For a deposit-monitoring service tracking a million addresses it is an extra round trip per address, or a hand-rolled bech32 and bech32m decoder in your critical path. Storing script type as a queryable field on every input and output removes the choice entirely.

Why two Bitcoin APIs report different balances for the same address

This is the finding that should change how you test a provider. We asked three APIs for the balance of 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, the genesis address, on 23 August 2026.

Blockstream Esplora returned 5,743,007,305 satoshis across 65,514 transactions. mempool.space returned exactly the same figure, to the satoshi. BlockCypher returned 10,744,043,593 satoshis. That is 57.43007305 BTC against 107.44043593 BTC, a difference of just over 50 BTC on an address that thousands of people have looked at.

Neither is a bug. The 50 BTC coinbase reward of the genesis block is unspendable and, by a quirk of how Bitcoin Core builds its database, was never added to the UTXO set. Providers that derive balances from the UTXO set therefore exclude it. Providers that sum the historical outputs paid to the address include it. Both conventions are honest and both follow from documented behavior of the underlying software rather than provider error.

The lesson is not that one API is wrong. It is that "balance" is a convention, and your ledger inherits whichever convention you bought without being told. Genesis is an extreme case, but the same class of divergence shows up wherever a provider takes a defensible position on an edge: unspendable outputs, outputs to nonstandard scripts, and mempool versus confirmed state. Before you commit, pick five addresses with awkward histories, query every candidate provider, and diff the numbers. If they all agree you have learned something. If they do not, you have found the question to ask sales.

How much of Bitcoin uses Taproot, and why the answer keeps changing

The other reason to hold script type as data is that address type shares get quoted in roadmap documents and almost never carry a definition. We fetched all 3,905 transactions in block 963,670, mined 23 August 2026 at 03:51:27 UTC, and measured the same block four ways.

Taproot was 12.54 percent of the 9,784 outputs created. Remove the 1,849 OP_RETURN outputs, which carry no address at all, and it becomes 15.46 percent. Weight by BTC instead of by output count and it drops to 3.85 percent. Look at inputs being spent rather than outputs being created and it is 13.27 percent. Four correct answers, one block.

Legacy P2PKH shows the split even more sharply: 4.60 percent of outputs created, which reads like a dying format, against 28.82 percent of the value. One transaction explains most of the second number. Transaction 58e4dbcb185b976216a9b409f77bca843af68ac7afee692474012fb71f242a0c put 1,687.81 BTC into legacy outputs, which is 87 percent of all legacy value in the block. We re-fetched it to check what it was really doing: three inputs, two outputs, a fee of 988 satoshis, and 1,633.31 BTC going straight back to an address that was already an input. The actual payment was 54.5 BTC. The rest was change, the same distortion that inflates headline on-chain transaction volume.

So value-weighted format shares move on individual whales and are unstable block to block, while count-weighted shares track what wallet software is doing and stay comparatively steady. If you are sizing a migration, count. If you are sizing exposure, weight by value. Do not let a vendor chart decide which one you got.

There is a third reading that only exists because the type is recorded on inputs too. Legacy was 12.37 percent of the inputs spent in that block against 4.60 percent of the outputs created, so coins left legacy addresses about 2.7 times more often than they arrived at one. That asymmetry is the migration in progress, and no balance endpoint can show it.

What about rate limits and running your own node?

Free public endpoints are excellent for development and a liability in production. BlockCypher's documentation states a free ceiling of three requests per second and one hundred per hour, resetting on the hour in UTC, and it is the only one of the four that returns an x-ratelimit-remaining header so you can see where you stand. mempool.space runs an open API with undisclosed limits enforced by HTTP 429, which is generous until the day it is not. We have written up the measured rate limits across the main Bitcoin APIs separately.

Paged endpoints are the quieter constraint. Esplora returns block transactions 25 at a time, so pulling one busy block took over 150 sequential requests and around eight minutes. That is fine for a script and impossible for a reconciliation job.

Running your own node solves trust and limits, and introduces operations. A node gives you the raw chain with no rate limit and no vendor convention, but Bitcoin Core alone will not answer "what is the balance of this address" without an address index, and it will not answer historical questions at query speed at all. We costed a production node in AWS at roughly 390 to 430 dollars a month before anyone maintains it. Teams that go this route usually end up building an indexer, which is the actual product they were trying to avoid buying. Whichever way you go, put the dependency under continuous endpoint monitoring from day one, because a data source that fails quietly is worse than one that fails loudly.

Which Bitcoin address API should a wallet team choose?

Rough guidance, assuming a US team building something that has to reconcile.

For prototypes and internal tools, mempool.space is the fastest to integrate and was the quickest responder in our tests at 0.13 seconds. Accept that you will add your own address parser for script type.

For batch balance checks across many addresses, BlockCypher's semicolon-separated batching is the most convenient of the public options, and it is the only one exposing a rate limit header. Watch the balance convention, and see our notes on checking Bitcoin address balances in bulk.

For anything requiring history, script type, or joins across addresses, transactions and time, an indexed database is the right shape of tool rather than a lookup endpoint. That is what we built: script type on every input and output, exact balances to the satoshi with a stated convention, address lookups and full UTXO detail over REST, and SQL when the question is a join. A broader head-to-head sits on our comparison of the main Bitcoin APIs.

Whatever you pick, run the diff test first. Five awkward addresses, every candidate provider, and a spreadsheet. It takes an afternoon and it is the cheapest insurance you will buy this quarter. Everything here is informational on-chain data and engineering guidance, not financial, investment or legal advice.