Blockchain.com · Rate Limits

Blockchain Rate Limits

Blockchain.com publishes distinct rate-limit policies for each of its four developer surfaces. The Bitcoin Data API and Simple Query API are throttled per IP; the Charts/Stats family is throttled per IP with sampling guidance for large series; the Exchange REST API is throttled per API key; the Exchange WebSocket caps client-to-server messages at 1200 per minute per connection. Limit-raise requests for the Exchange are handled by support.

Blockchain Rate Limits is the machine-readable rate-limit profile for Blockchain.com on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 7 rate-limit definitions, measuring requests_per_second, requests_per_period, requests_per_minute, and messages_per_minute.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serverThrottled.

Tagged areas include Rate Limiting, Cryptocurrency, Bitcoin, and Exchange.

7 Limits Throttle: 429
Rate LimitingCryptocurrencyBitcoinExchange

Limits

Bitcoin Data API (rawblock, rawtx, rawaddr, multiaddr, unspent, latestblock) IP
requests_per_second
see Blockchain.com Data API docs (per-IP throttle, raise via support)
Bulk integrations should batch with multiaddr and prefer the WebSocket for new-block / new-tx streams to avoid polling.
Simple Query API (/q/*) IP
requests_per_period · second
1
Hard cap: one request per 10 seconds per IP. Heavy users should cache locally.
Charts API (api.blockchain.info/charts/*) IP
requests_per_period
see charts API guidance — use sampled=true and rollingAverage to reduce payloads
Large `timespan` requests are expensive. The `sampled=true` flag downsamples to ~1500 points and is the recommended default for dashboards.
Stats / Pools API IP
requests_per_minute
unpublished — light polling (1/min) is fine
Ticker / tobtc IP
requests_per_minute
unpublished — values cache for ~15 minutes upstream
Exchange REST API key
requests_per_second
see api.blockchain.com/v3/ — per-key throttle; raise via support
Concurrent reads + writes are accounted independently. Bulk-cancel via DELETE /orders is cheaper than cancelling individual orders.
Exchange WebSocket (mercury-gateway) connection
messages_per_minute · minute
1200
Client-to-server message cap. Excess messages return `event: rejected`; resume after one minute. Server-to-client snapshot/update messages are not delayed.

Policies

Sequence numbers
Every Exchange WebSocket message carries a monotonically increasing `seqnum`. Gaps signal dropped messages — reconnect and rebuild state on gap detection.
API key whitelisting
Exchange API keys can be scoped to read-only and bound to a specific IP list at creation time. Use separate keys for separate workloads to localise rate-limit incidents.
Backoff and caching
Public data endpoints expect callers to cache locally. Use the WebSocket for change-driven updates rather than polling REST endpoints.
Raise limits via support
Exchange and Pay partners can request higher rate limits via Blockchain.com Support; public data limits are not raised on request — design around them.

Sources