Blog·Updated August 19, 2026

Bitcoin Data Infrastructure: What Your App Actually Needs

Bitcoin Data Infrastructure: What Your App Actually Needs

Every Bitcoin application, from a wallet to an ordinals marketplace to a treasury dashboard, sits on top of the same small set of questions. What is the chain tip right now? Which outputs does this address control? What fee will get my transaction confirmed in three blocks? Did my broadcast actually land? Bitcoin data infrastructure is the layer that answers those questions fast, consistently, and without falling over when your traffic doubles.

This guide covers what that layer has to do, where teams get it wrong, how to decide between running your own node and buying an API, and what a production Bitcoin data API looks like in practice.

TL;DR

Bitcoin data infrastructure is three layers, and most teams only price one of them. A node gives you consensus. An index gives you the lookups Bitcoin Core does not keep. An API gives you something your application can actually call. Node providers sell you the first. A Bitcoin data API sells you all three, and the gap between them is measured in months of engineering.

Rule of thumb: if Bitcoin infrastructure is your product, run it yourself. If it is a dependency of your product, buy it, and pick a vendor whose roadmap points where yours does.

Where Nexus fits: Bitcoin, Cardano and Midnight from one account and one base URL, flat monthly pricing from $29 with a 7-day trial, and ordinals and runes indexed alongside the standard chain data. The full endpoint list is further down.

What "Bitcoin data infrastructure" actually means

The phrase gets used for three different layers, and conflating them is the first mistake teams make.

The node layer. Bitcoin Core itself. It validates blocks, holds the UTXO set, tracks the mempool, and exposes JSON-RPC. It is authoritative and it is also deliberately minimal. Bitcoin Core is not designed to answer "show me every transaction this address has ever been in" quickly.

The index layer. Software that reads the chain and builds the lookups Bitcoin Core does not maintain by default: address history, an ordinals and runes index, spent-output tracking. This is where most of the operational cost lives.

The API layer. The HTTP surface your application actually calls, with authentication, rate limiting, pagination, caching, and error semantics that make sense to a client developer.

A Bitcoin node provider sells you the first layer. A Bitcoin data API sells you all three. The difference matters enormously for how much code you end up writing, and it is the single most common reason a provider that looked cheap turns out not to be.

The seven things a Bitcoin data layer has to get right

Chain tip and reorg handling. Your application needs the current best block, and it needs to know when the chain reorganises underneath it. A one-block reorg is routine. If your data layer reports a transaction as confirmed and then the block disappears, and your API gives you no way to detect that, you will ship a bug that only appears in production.

Address UTXO sets. Bitcoin has no accounts. To spend, you need the exact list of unspent outputs an address controls, with values and outpoints. Bitcoin Core will not give you this for an arbitrary third-party address without extra indexing. Every wallet and every transaction builder depends on it.

Confirmed balance separate from mempool state. A user seeing an incoming payment wants to know it exists. Your coin selection code must not spend it until it confirms. Those are two different numbers, and your data layer should expose both, distinctly.

Fee estimation. Bitcoin fees move fast. You need sat/vB estimates keyed by a target confirmation window, sourced from real network conditions, or your users will overpay in quiet periods and get stuck in busy ones.

Mempool visibility. Count, virtual size, and a fee histogram tell you what the current competition for block space actually looks like. This is what powers a credible "your transaction should confirm in about X" estimate and a working replace-by-fee flow.

Ordinals and runes. If you touch Bitcoin NFTs or fungible tokens on Bitcoin, you need a separate ord-style index: which inscriptions and rune balances sit at an address, which are carried by a specific outpoint, and metadata by inscription ID or rune name. Getting this wrong means accidentally spending an inscription as ordinary sats, which is the most expensive bug in the category.

Broadcast with honest error semantics. When you submit a signed transaction, bitcoind returns reject codes. A good API maps them to HTTP status codes you can branch on, so "already in the chain" is a different outcome from "this transaction is invalid". A bad API returns 500 for both and leaves you pattern-matching an error string.

Run your own node, or buy an API?

Both are defensible. The decision comes down to what your team should be spending its time on.

Running your own stack means Bitcoin Core with txindex=1 if you need arbitrary historical transaction lookups, several hundred gigabytes of storage that grows every month, an initial block download measured in days, plus a separate ord indexer if you need inscriptions and runes. Add monitoring, alerting, an on-call rotation, and a plan for what happens when the machine dies during a fee spike. You get full control, no per-request cost, and no vendor in your dependency chain.

Buying an API means you get the index layer someone else operates, a documented HTTP surface, and a support path when something breaks at 3am. You give up control and you take on vendor risk, which is real: providers change direction, reprice, or deprioritise a chain.

The honest rule of thumb: if Bitcoin infrastructure is your product, run it yourself. If Bitcoin infrastructure is a dependency of your product, buy it, and pick a vendor whose roadmap points the same direction as yours.

How to evaluate a Bitcoin data provider

Work down this list before you write a line of integration code.

Check the endpoint surface against your actual feature list. Not the marketing page, the API reference. If you need runes, find the runes endpoint. If you need mempool fee histograms, find that endpoint. Missing pieces become custom infrastructure you did not budget for.

Read the pricing model, not the price. Flat request pools tell you your monthly bill before you sign. Compute-credit and compute-unit models weight different methods differently, so an identical workload can cost wildly different amounts across providers, and you cannot forecast until you have run for a month. Across the wider market the same call can be metered at 1 credit by one vendor and 200 by another, which is why this is the most common source of surprise infrastructure bills.

Find the rate limits and the burst allowance. A monthly quota tells you nothing about whether your traffic spike gets throttled. You want requests per second and burst depth, published.

Look at what happens when you exceed the plan. A hard 429, overage billing, or a degraded floor are all acceptable. Not knowing which one you get is not.

Check the changelog, not the roadmap. A roadmap is a statement of intent. A changelog is a record of shipping. If the chain you care about has a changelog that stopped a year ago while another chain's is active, you have learned where the engineering effort goes.

Test the errors deliberately. Submit an invalid transaction. Query a nonexistent txid. Call an endpoint your plan does not include. The quality of those three responses tells you more about a provider than any benchmark on a landing page.

What Nexus covers on Bitcoin today

Nexus exposes Bitcoin over the same REST surface, the same X-Api-Key header, and the same docs site as its Cardano and Midnight coverage. Networks are selected with a network query parameter, and Bitcoin supports bitcoin-mainnet and bitcoin-testnet4.

Two details are worth calling out, because they are exactly the sharp edges described above. The address endpoints separate confirmed balance from combined chain-and-mempool statistics, so your coin selection logic and your user-facing balance can deliberately use different sources. And the submit endpoint maps bitcoind reject codes onto HTTP status codes, so codes -22, -25, and -26 come back as 400 while -27, already in the chain, comes back as 409. You branch on the status instead of parsing an error string.

Being straight about the boundaries: this is a Bitcoin data and broadcast API. Nexus does not do server-side Bitcoin transaction construction (the transaction builder is a Cardano add-on), and it does not run Bitcoin L2 or DeFi-specific tooling. If those are your requirements, weigh a Bitcoin-specialist platform. The full reference, with a live playground on every endpoint, is at nexus.gerowallet.io/docs.

Your first Bitcoin call

Create an account, generate a key scoped to Bitcoin mainnet, and read the chain tip.

const res = await fetch(
'https://nexus.gerowallet.io/api/btc/chain/tip?network=bitcoin-mainnet',
{ headers: { 'X-Api-Key': 'nxs_your_api_key_here' } }
);

const tip = await res.json();
console.log(tip);

One thing to know before you start: each Nexus API key is scoped to one chain and one network. If you are building across Bitcoin and Cardano you create a key for each, under the same account, the same base URL, and the same billing. The scoping rule, and the error you get when a request and a key disagree, are documented in Authentication.

Pricing, quotas, and rate limits

Nexus prices in flat monthly tiers with published request pools and rate limits, so you can model your infrastructure cost before you integrate.

Metered responses carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so you can track your monthly quota from inside your own application rather than from a dashboard. Optional add-ons cover market data, wallet analytics, server-side transaction building for Cardano, a DEX aggregator, an MCP server for AI agents, and IPFS. A Dedicated tier with isolated infrastructure exists for compliance-sensitive workloads. There is no free tier, and there is a 7-day trial on the Builder plan, which is enough to run a real integration rather than a toy one.

Start building: get a key and start the 7-day Builder trial.

Common questions

Do I need my own Bitcoin node if I use a data API?
No, for the large majority of applications. You need your own node when you require full validation guarantees with no third party in the trust path, or when your query volume makes per-request pricing more expensive than operating hardware.

What is the difference between a Bitcoin node provider and a Bitcoin data API?
A node provider hands you JSON-RPC access to Bitcoin Core. A data API adds the index layer on top, which is where address history, ordinals, runes, and mempool analytics live. If a provider only offers RPC, plan to build and operate that index layer yourself.

How do I handle reorgs safely?
Track block height and hash together, never height alone. Re-verify recent confirmations against the chain tip before treating them as final, and choose a confirmation threshold that matches the value at risk.

Can I query ordinals and runes through the same API as regular Bitcoin data?
With Nexus, yes. The ordinals endpoints resolve inscriptions and rune balances by address, by outpoint, and by inscription ID or spaced rune name, using the same key and the same base URL as the rest of the Bitcoin surface.

Does Nexus support chains other than Bitcoin?
Yes. Cardano has the deepest coverage, including stake pools, assets, scripts, Conway-era governance, and a server-side transaction builder. Midnight covers transactions and DUST. See Inside the Nexus API for the full platform surface.

Where to go next

Bitcoin data infrastructure is not a single product decision. It is a set of guarantees your application will quietly depend on for as long as it exists. Pick the layer you actually need, read the changelog before you read the landing page, and prefer pricing you can forecast over pricing you have to reverse-engineer.

If you are moving off an existing provider rather than starting fresh, the endpoint-level migration map in Maestro Alternatives for Bitcoin and Cardano covers the mechanics.

To evaluate Nexus against your own workload, the fastest path is a real call against real data. Get a key and start the 7-day Builder trial, work through the Quick Start, and point it at an address whose answer you already know.