Best Bitcoin Ordinals API for Wallet and Marketplace Teams

If you are reading this because a build broke, here is the two sentence version. Your Hiro ordinals calls are not misconfigured, and you are not missing an auth header. The endpoints are gone on purpose, and the URL the error hands you no longer exists.

We called every realistic option on 2 September 2026 from one US machine, without API keys, inside a few minutes. What follows is what actually came back rather than what the marketing pages claim.

What we called, and what came back

Four providers in one narrow niche, and four different HTTP status codes for what is conceptually the same answer: you cannot have this right now. That is worth designing around. A client that collapses everything into a generic request failed will retry forever against a 410 that will never succeed, and will treat a 402 payment challenge, which is recoverable, exactly like a 403 auth error, which is not. Handle them separately.

Is the Hiro Ordinals API deprecated?

Yes, completely. Hiro announced the deprecation of its Ordinals, Runes, BRC-20 and Bitcoin Indexer APIs effective 9 March 2026 and pointed developers at Xverse. On 2 September 2026 we called four of those endpoints, the inscriptions list, the ordinals root, the Runes etchings list and the BRC-20 token list. Every one returned HTTP 410 Gone in 0.35 to 0.37 seconds with an identical 164 byte JSON body. This is a finished shutdown, not a wind down.

Two details are easy to miss. First, 410 rather than 404 is deliberate and correct: it tells a client the resource is permanently gone, so retry logic and crawlers should give up instead of polling. Second, the dead endpoint still returns rate limit headers, ratelimit-limit: 20, so a retry loop hammering a corpse is still being counted against a quota.

Important nuance, because the 410 reads worse than it is: only Hiro's Bitcoin Layer 1 surface was retired. Its Stacks APIs are healthy. We called them the same hour and the node info endpoint reported a burn block height of 965,186, which matched the Bitcoin tip we had measured independently minutes earlier. If you build on Stacks, none of this touches you.

What replaced the Hiro Ordinals API?

Hiro named Xverse, and Xverse serves ordinals data from api.secretkeylabs.io under a /v1/ordinals/ prefix, with endpoints keyed by address and by transaction. That address key matters more than it sounds, and we will come back to it.

The awkward part of the migration is the pointer. The 410 body politely includes a documentation_url aimed at Hiro's ordinals migration guide. We followed it and got HTTP 404, and the parent ordinals documentation page 404s too, while the docs root still loads normally. Both pages were removed along with the product. So the machine readable breadcrumb inside the error leads nowhere, which is exactly the situation where an engineer burns an afternoon assuming the fault is local. It is not. We wrote the full teardown on our Hiro Ordinals API alternative page, and there is a separate comparison of what Xverse covers as an ordinals API.

Why do ordinals APIs return HTTP 402?

Because a real chunk of this niche has moved to pay per call. HTTP 402 Payment Required sat unused in the spec for decades and is now showing up in production: Xverse returns it with a paymentauth.org problem type and a unique challengeId per request, and Ordiscan returns it citing the x402 protocol. Instead of buying a monthly key, your client settles a small payment per request, which suits automated agents that would rather not manage credentials.

It is a reasonable model, and it changes your cost profile in a way worth planning for. A flat monthly plan caps your downside; per call billing turns API access into a variable line item that moves with traffic, and a retry storm against a failing dependency becomes a bill rather than just an error rate. If you go this route, put a real-time alert on that budget line before you ship, not after the first surprising invoice. Cap retries, and back off hard on 402s you have not funded.

Can you query Bitcoin ordinals by address?

Sometimes, and this is the single question that should drive your choice. Ordinals indexers vary enormously in whether a holder address is a first class key or an afterthought. Xverse exposes an address UTXO endpoint. UniSat indexes BRC-20 by holder. Ordiscan is strongest on inscription identity.

Node providers, by contrast, cannot do it at all. We measured that separately: no managed Bitcoin RPC endpoint can answer what an address holds, because Bitcoin Core keeps no address index, and the one Core call that could sweep for it is disabled on shared infrastructure. QuickNode's own ordinals product is keyed by inscription id, block, sat and rune, not by holder, which is documented on our QuickNode Bitcoin API comparison. If you want the underlying measurement, it is in our Bitcoin RPC node provider comparison.

One more caveat that catches teams late: BRC-20 balances are not protocol state. They exist only as the output of an indexer applying a set of rules to inscriptions. Two reputable providers can therefore report different balances for the same address and both be defensible. If your product shows a user a number, decide now which indexer is your source of truth and say so in the interface.

Which Bitcoin ordinals API is best for wallet and marketplace teams?

There is no single winner, so match the tool to the question you are actually asking.

Most production stacks end up running two of these rather than one. A node provider handles writes, an index handles reads, and the mistake is expecting either to cover the other. Our own position is the read side: we serve address history from the 2009 genesis block over REST, plus SQL and dashboards over the indexed chain, which grows with every new block, which you can try on the Bitcoin ordinals API page or against raw outputs on the Bitcoin UTXO data page. We do not mint, etch or broadcast, and we would rather say that plainly than let you find out in week three.

How much does a Bitcoin ordinals API cost?

Less predictably than it used to. The monthly key model still exists at UniSat and at indexers that sell plans, and pricing there behaves the way SaaS pricing normally does. The pay per call providers are the change: your bill tracks request volume directly, with no published monthly figure to anchor on, so the honest answer to what it costs is that it depends on your traffic shape and your retry policy. The Bitcoin ordinals API page sets the billing models side by side and covers when self-hosting the ord indexer starts to pay off.

Whichever model you pick, budget for the migration itself. Hiro gave notice and named a successor, which is better behavior than most deprecations get, and teams still got caught because the endpoint kept working right up until it did not.

What we did not measure

Being clear about the limits, because a comparison that hides them is not worth much. We called these endpoints without API keys, so we measured the unauthenticated surface: what a new integrator hits on day one, not what a paying customer sees. Response times came from a single US machine on one morning and should be read as rough magnitudes, not benchmarks. We did not evaluate data accuracy, index completeness or how quickly each provider reflects a new inscription, all of which matter enormously and none of which can be judged from a status code. And we did not test Xverse or Ordiscan behind a funded payment channel, so we cannot speak to their behavior once you are actually paying.

What the measurement does settle is the part teams get wrong first: which of these endpoints still exist, what they return when you have no credentials, and which of them will ever answer a question that starts with an address.