Best Bitcoin API for Crypto Tax Software and Cost Basis

If you are building or buying the data layer under a crypto tax product, the vendor comparison usually gets framed as coverage: how many chains, how many exchanges, how many integrations. That is the wrong first question for Bitcoin. Bitcoin is one chain and it is fully public. The hard part is that a tax engine has to produce a dollar figure, and dollars are not on the chain.

We measured the gap rather than describing it. Everything below was run against live endpoints on 8 September 2026, and you can reproduce all of it in about two minutes.

What does crypto tax software actually need from a Bitcoin API?

Four things, and they are not equally easy to get. First, the complete transaction history for an address or an extended public key, with nothing dropped. Second, exact amounts in satoshis, which every provider gets right. Third, the confirmed block timestamp, so you know when the disposal happened. Fourth, the USD value at that timestamp, which is the one nobody hands you.

There is a fifth requirement that people discover late: lot lineage. To compute a gain you need to know which earlier output funded the coins being spent, because that output carries the basis. Bitcoin makes this unusually tractable compared with account-based chains, since every spend names the exact prior output it consumes. A UTXO model is a lot-tracking model already. Most APIs simply do not expose it as one.

Do any Bitcoin APIs return the USD value of a transaction?

We took one confirmed transaction from the chain tip and asked five well known providers for it, then walked the entire JSON response looking for any key containing "usd" or "price", and separately for those substrings anywhere in the raw body. Here is what came back.

Four providers answered fully and none of them carries a fiat field. That is not an oversight on their part. These are block explorers, and a block explorer reports what the chain says. The chain says 0.0412 BTC moved. It does not say that was $4,300.

The consequence for your architecture is concrete. Every transaction your tax engine ingests has to be joined against a separate price series, and you now own a second data dependency with its own coverage, latency and revision behavior. If that join is wrong, every downstream number is wrong, and it will be wrong quietly.

How do you get the historical BTC price for each transaction?

You pick a price source, pick a convention, and then document both, because auditors ask. The convention matters more than people expect. A transaction confirmed at 03:51:27 UTC can be valued at the daily close, the daily open, the hourly candle close, a volume weighted average across venues, or the spot rate on one specific exchange. Those choices produce materially different gains on a volatile day, and all of them are defensible.

Two traps show up repeatedly in implementations we have looked at. The first is using the broadcast time instead of the confirmed block time; a transaction can sit in the mempool for hours, and only the block timestamp is verifiable after the fact. The second is trusting block timestamps to be monotonic. They are not. When we measured spent output lifespans across a block we found 15 inputs with a negative lifespan, meaning the spending block carried an earlier timestamp than the block that created the output. Bitcoin permits this within consensus limits. If your pricing join assumes time only moves forward, those rows will silently take the wrong price.

This is the reason we store the valuation alongside the chain data rather than beside it. In our schema the outputs table carries price_at_creation_usd next to value_btc, address, script_type and a spent flag, so the acquisition value travels with the lot instead of being recomputed by every consumer. You can see the full field list and query patterns on the Bitcoin cost basis API page.

Which cost basis method does US crypto tax software have to support?

More than one, and since 2025 the rules got structurally harder for engineers rather than just for filers. Revenue Procedure 2024-28 ended universal cost basis for digital assets and requires wallet-by-wallet or account-by-account tracking, effective 1 January 2025, with a safe harbor that let taxpayers allocate remaining unused basis to each wallet as of that date. On the reporting side, brokers began reporting gross proceeds on Form 1099-DA for sales occurring in 2025, and adjusted basis reporting follows for 2026. The practical fallout for preparers is the transferred-in lot with a blank basis box, which our guide to 1099-DA reconciliation software for bitcoin works through with measured deposit data. None of this is tax advice, and your users should take their own; we are describing what it means for the data model.

What it means is that a portfolio-level total is no longer sufficient. Every lot has to be attributable to a specific wallet, which pushes you toward per-address, per-output tracking rather than an aggregated balance. That is precisely the shape of the UTXO set, so on Bitcoin the compliant model and the natural model are the same model. You need each output's creating transaction, its address, its value, its acquisition price and whether and when it was spent. Our Bitcoin UTXO data page covers how that set is exposed, and the mechanics of matching disposals to lots are worked through in our guide to calculating Bitcoin cost basis.

What breaks when you move from a demo to real customers?

Three things, reliably. Extended public keys are the first. Tax users hand you an xpub, not a list of addresses, and derivation scanners stop after roughly 20 consecutive unused addresses. That gap limit is a convention, not a rule, and a user who generated addresses out of order loses history without any error being raised. Handling that properly is its own piece of work, which is why we split it out onto the xpub balance API page.

Paging is the second. Public explorers return address history 25 transactions at a time. That is fine for a personal wallet and unworkable for a heavy one. The busiest address we track carries over 2.3 million transactions; pulling a two and a half day slice of it took 90 sequential requests. If your ingestion is a naive loop over every customer address, your onboarding time scales with your customers' trading volume, and it will be the thing that breaks first on a January signup surge.

The third is reorgs and revisions. A block that looked final can be replaced, and a price series can be revised after the fact. Tax numbers get filed, so you need to know whether a figure you produced in March still reproduces in September. Storing the inputs to each calculation, not just the output, is what makes that answerable.

Should you build the Bitcoin layer or buy it?

Build it if Bitcoin data is your product. Buy it if your product is tax logic, jurisdiction coverage and a filing experience, which is where the actual differentiation and the actual pricing power sit. Running your own indexed node is real infrastructure: we costed a production setup in AWS at roughly $390 to $430 a month before anyone's time, and that estimate buys you the raw chain, not the price join, not the xpub derivation and not the lot accounting.

The honest middle path most teams land on is buying the indexed chain and owning the tax logic. That keeps your engineers working on the part customers pay for. If you are evaluating vendors, be specific about what you are buying: some sell you finished metrics rather than the rows underneath, which is a fine trade until an auditor asks you to reproduce a number. We wrote up that distinction while measuring one of the better known metrics vendors on our Coin Metrics alternative page, including which metrics its free tier withholds.

One practical note from the accounting side of these projects: whatever your engine outputs, someone downstream still has to get the realized gain lines into a general ledger. If the client's books live in QuickBooks, exporting your results and then converting that CSV into a QBO file the accounting system will accept is usually a cleaner handoff than asking a bookkeeper to key transactions by hand.

What to ask a Bitcoin data vendor before you sign

Five questions that separate vendors quickly. Do you return a USD value at the transaction's block timestamp, and which convention is it? Can I retrieve the full history of an address without paging limits that make large wallets impractical? Do you expose the UTXO set with a spent flag, or only balances? Can I query with SQL, or only through fixed endpoints? And can I reproduce any number you publish from the rows you give me?

That last one is the test we would apply hardest. A tax product's worst day is an examination it cannot support with evidence. If your data vendor cannot show its work, you cannot show yours. BitcoinDatabase exposes blocks, transactions, inputs, outputs and the UTXO set over REST, with address history back to 2009, and over SQL on the indexed chain, which grows with every new block, with acquisition price stored on the output, so the arithmetic behind every figure stays open to you. Start with the cost basis API, or query the chain directly from the API documentation.

Measurements in this article were taken on 8 September 2026 against live public endpoints. Provider behavior and pricing change; re-run the checks before relying on them. This is informational on-chain data and engineering guidance, not tax, legal or investment advice.