Rate limit

Almost every API card in this catalogue records a rate limit, and it is the least comparable number on the page. Two products can each publish one honest figure and still give you no way to work out which will run out first, because the figures are counted in different things, charged against different identities and raised by different levers.

How it works

Four families are in use across the cards here, and each answers "how much" with a different noun.

Requests per interval. The simplest form. Coinbase documents ten requests per second per IP on its Exchange public endpoints, bursting to fifteen, and fifteen per second per profile on the private ones, bursting to thirty. The unit is the request, every request is the same size, and you can plan against it with arithmetic.

Weighted cost per interval. Binance publishes a REQUEST_WEIGHT budget per minute alongside a raw-request ceiling, and every response returns the running total in an X-MBX-USED-WEIGHT header so you can watch it drain. The weights are not uniform, which is the whole point of the design and the trap in it — the Binance API card records a klines call at 2, an aggregate-trades call at 4, a trades call at 25, and an order book at 5 for depth 100 but 250 for depth 5,000. The same budget is three thousand candle pulls or twenty-four deep book snapshots.

A counter that decays. Kraken gives each REST user a call counter starting at zero with a ceiling and a drain rate set by verification tier — a maximum of 15 on Starter and 20 on Intermediate and Pro, decaying at 0.33, 0.5 and 1 per second respectively. Ledger and trade-history calls add 2, most others add 1, and order placement runs on a separate limiter entirely. Nothing here is per minute; the question is what your sustained rate is against the drain.

Credits. A monthly balance, usually alongside a per-minute ceiling, and the credit is rarely a call. Glassnode spends one credit per request per asset — one for Bitcoin, two for anything else — and only when data leaves, so browsing costs nothing and an export costs per series. CoinAPI charges one credit per 100 data points on any call that uses the limit parameter. Dune bills in proportion to the compute a query used and publishes no per-query formula, so the cost is known after execution. CryptoQuant grants credits monthly and its card says plainly that a credit is not a call.

What the headline number hides

Who is being charged. Per IP, per key, per profile or per endpoint are four different architectures. A per-IP limit means every process behind one NAT shares one budget and a serverless deployment shares it with strangers; a per-key limit means a second key is the fix, and a per-IP one means it is not.

Whether the two axes move together. On the CoinGecko API card the paid ladder raises both, but not in step — the Lite plan quadruples the monthly credit grant without raising the per-minute ceiling at all, so upgrading for throughput buys allowance instead. Glassnode bundles 50 credits a month with 5 requests a minute on entry and climbs to 600 a minute higher up.

Who is doing the limiting. CCXT paces requests client-side against constants compiled into each exchange class rather than against anything the venue reports, so a venue that tightens a limit quietly will ban you before the library knows. The Hyperliquid Python SDK does no client-side limiting and no retries at all, by design. In both cases the number on the vendor's page is not the number your process is obeying.

Whether there is a number. Laevitas publishes no REST rate limit on its site or in its OpenAPI document — the gateway returns X-RateLimit headers, so you discover the ceiling at runtime on a 500-dollar-a-month product. Artemis says "limited queries, daily rate limits" and prints no figure. CoinAnk renders an API comparison table whose plan columns are labelled Plan1 to Plan4, with rate limits filled in and prices left out.

Why it matters here

The mistake a headline number invites is a straight comparison — 1,000 requests a minute against 10,000 credits a month, and the first looks like the larger product. They are not on the same axis. The per-minute figure is a speed limit, which you can bump into forever without ever exhausting; the monthly credit grant is a budget, which one backfill can spend in an afternoon and which then returns nothing until it resets. The right question is not which number is bigger but which one your workload runs into.

Two jobs make that concrete. A one-off historical pull wants a large credit balance and does not care about throughput, because a slow loop finishes overnight. A live dashboard or an alerting process wants a high per-minute ceiling and a small, predictable spend, because it makes the same few calls forever. A plan chosen for the wrong one of those fails in a way the pricing page did not describe.

Three things are worth checking before a key is bought. Convert the limit into your own unit first — calls your process will actually make, per hour, at the weights or credit costs the vendor publishes for the specific endpoints you will hit, not the cheapest one. Check what failures cost, because CoinGecko documents that 4xx and 5xx responses count against the per-minute limit like any other request, and a retry storm on a degraded upstream spends the budget twice. And find out what the escalation is — a 429 with a retry hint is recoverable in code, whereas an automatic ban that scales from two minutes to three days, as Binance documents, is an outage you have to sit out.