Bitcoin API Rate Limits Compared: Four Providers Tested

Rate limits are the reason teams leave free Bitcoin endpoints, and they almost never leave on a planned date. They leave on the afternoon a batch job starts returning 429s while a customer is waiting on a deposit. The frustrating part is that the limit is usually invisible until you cross it.

So rather than repeat what the docs claim, we called the endpoints and read what came back. Everything below was tested on 11 August 2026 between 00:54 and 00:56 UTC, from a single US server, using ordinary single requests rather than a burst. We did not try to trigger a 429 by hammering anyone, because that is abusive and it would not have told us anything the headers did not.

What we tested and when

Four providers, each called on a cheap, uncontroversial endpoint: the current chain tip or a network summary. The point was not to benchmark speed. It was to find out what each provider is willing to tell a client about its own limits before that client gets throttled.

Only one provider tells you where you stand

BlockCypher was the single provider in this test that answers the question a client actually needs answered. Its response to an unauthenticated call carried x-ratelimit-remaining: 1, which is the number of requests left in the current window for the calling IP. In our case that IP is a shared server that had evidently spent nearly all of its hourly allowance already, so the value was almost exhausted. That is not a complaint about BlockCypher. It is the opposite: the header is exactly why we knew.

With a header like that you can write a client that slows itself down before it fails, logs when quota is running low, and decides to upgrade based on data. Without one, your only feedback channel is the error. That difference sounds academic until you are the one reading a stack trace at 2am, and it is a large part of why the entry price on a paid plan is rarely the number that decides a migration. We put the full price and limit picture side by side on our Bitcoin API comparison.

Blockchair sits in a middle position. Its network statistics endpoint answered our unauthenticated request without complaint, but its documentation pages return 401 without a key, and a multi-address dashboard request we made in an earlier test came back with code 430 and a message about the IP being temporarily blacklisted. So the limit is real and it is enforced; it is simply not something you can read.

What the response headers actually revealed

The headers are worth reading even when they say nothing about quota, because they tell you how fresh the answer is and what is serving it. mempool.space returned cache-control: max-age=1, a permissive CORS header, and two headers that name its own stack: x-powered-by: mempool-electrs 3.4.0-dev and x-bitcoin-version: /Satoshi:30.0.0(@wiz)/. That second one is unusually candid. It tells you which Bitcoin Core version is behind the index.

Blockstream returned cache-control: public, max-age=10 and X-Cache-Status: EXPIRED, which shows the response is served through a CDN with a ten-second cache window. For a chain-tip query, ten seconds is harmless. For anything where you are polling for a state change, it means your poll interval below ten seconds buys you nothing but rate-limit consumption. Polling faster than the cache is a common and completely invisible way to waste quota.

The off-by-one that quietly breaks reconciliation

While polling all four providers in parallel at 00:55:30 UTC, three of them reported the chain at 961,936 and one reported 961,937. That looks like a provider being a block ahead. It is not. Blockstream, mempool.space and BlockCypher return the tip height, and Bitcoin heights are zero-indexed because the genesis block is block 0. Blockchair's blocks field is a count, and a chain whose tip is at height 961,936 contains 961,937 blocks.

Both numbers are correct. They answer different questions. But if you are reconciling one provider against another, or writing an alert that fires when two sources disagree, this produces a permanent one-block discrepancy that looks like a lag bug and is not. It is worth writing down which semantic each field carries before you build anything on top of two providers, and it is the same class of problem as two explorers disagreeing on a balance: most of the numbers a Bitcoin API returns are indexer output, not protocol fields.

Fee estimates come back in two different shapes

The same divergence shows up in fee estimation, and here it is sharper because the units look identical. mempool.space's /api/v1/fees/recommended returned named tiers as integers:

{"fastestFee":2,"halfHourFee":1,"hourFee":1,"economyFee":1,"minimumFee":1}

Blockstream's /api/fee-estimates returned floats keyed by target block count:

{"3":2.006,"4":1.109,"5":1.109,"6":1.07,"17":0.49,"20":0.464}

Both are sat/vByte and both were correct at the time. But one gives you five opinionated buckets and the other gives you a curve you interpret yourself, and Blockstream's values go below 1 sat/vByte where mempool.space floors at 1. Swapping one provider for the other without adjusting your rounding will change the fee your wallet attaches. The mempool was quiet when we tested, with roughly 2,930 transactions waiting, which is why every figure is at or near the floor. On a busy day the gap between these two shapes matters a great deal more. Reading that state directly is what a Bitcoin mempool API is for.

What is the rate limit for the mempool.space API?

mempool.space does not publish a numeric rate limit for its public API. It is genuinely open, needs no key, and answered our request in 0.09 seconds, but the limits are enforced with HTTP 429 rather than documented in advance, and no header tells you how close you are. Higher-volume access is arranged directly with the project rather than sold at a public price, so there is no self-serve tier to upgrade into.

Does the Blockstream API have a rate limit?

Yes, though Blockstream does not publish the number either. Our unauthenticated call to the Esplora API succeeded and returned no quota header of any kind. Responses are served through a CDN with a ten-second cache, so a share of your traffic never reaches the origin at all. Treat it as a best-effort public good: excellent for development, unsuitable as the sole dependency for anything customer-facing.

What is BlockCypher's rate limit?

BlockCypher documents a free tier of up to 3 requests per second and 100 requests per hour, with webhooks and websockets limited to 100 per hour and 100 stored, and confidence lookups to 10 per hour. Hourly limits reset at the top of the hour UTC and excess requests receive a 429. Paid plans start at $119 per month, with a 10 percent discount for paying in Bitcoin. It is the only provider in this test that reports remaining quota in a header.

How do I handle a 429 from a Bitcoin API?

Back off exponentially, honor any Retry-After header, and never retry a write blindly. The important part is what you do before the 429: cache anything that changes slowly, batch address lookups instead of looping one call per address, and align your poll interval to the provider's cache window rather than to your own impatience. When an endpoint you depend on starts refusing traffic, you want that to reach you through a monitor watching the endpoint every 30 seconds rather than through a support ticket.

Are free Bitcoin APIs good enough for production?

For development, prototypes and internal tooling, yes, and the public endpoints tested here are well run. For anything that credits a customer deposit, prices a withdrawal or feeds a dashboard people rely on, no. The blocker is not the price but the absence of a commitment: none of the free endpoints here publishes a rate limit, an uptime figure or a support path, so there is nothing to design against and nobody to call. The engineering hours spent working around an unpredictable throttle usually cost more than the plan would have, a calculation we worked through in detail in our guide to how much a Bitcoin API costs.

What to build into your client regardless of provider

Four things earn their keep on every Bitcoin integration we have seen. Read the quota header if there is one, and record it as a metric rather than ignoring it. Set your poll interval from the provider's cache-control header, because polling faster than the cache is pure waste. Pin the semantics of every field you reconcile, especially heights and counts, since the one-block difference above is not a bug in anyone's code. And keep a second provider configured behind a flag, because the failure mode of a public endpoint is not a graceful degradation, it is a wall.

The deeper fix is to stop making the same request thousands of times. Most rate-limit pain we see comes from looping a per-address endpoint across a list that should have been one query. If your work looks like that, a dataset you can query in SQL, or a Bitcoin API that answers your question in a single call, removes the pressure entirely rather than rationing it. And if the reason you are calling a public explorer is that you did not want to run infrastructure, that is a solved problem in its own right, covered in our walkthrough on accessing a Bitcoin node without running one.

All figures tested 11 August 2026. Provider limits and prices change, so re-check before you rely on them. Informational on-chain data only, not financial or investment advice.