5 Fixes for Crypto API Rate Limits: Map Exchange Rules to Bots

September 5, 202612 MIN5 views

API rate limits cap the number of requests an exchange will accept from your application in a given time window, protecting the exchange’s infrastructure from overload and keeping access fair across all users. The immediate fix for a bot that keeps stalling is simple: inspect the response headers for limit, remaining, and reset values, then add adaptive backoff or move market data polling to WebSocket. Skip that step and your automated trading logic will eventually stall exactly when the market moves.

TL;DR:

Reading and respecting exchange response headers for limit, remaining requests, and reset time prevents unnecessary throttling and helps manage request flow effectively.

Moving market data polling from REST to WebSocket reduces quota consumption and minimizes the risk of hitting rate limits during high-frequency operations.

Knowing the specific rate limits and request weight models of each exchange, such as Gemini’s fixed requests per second or Kraken’s point system, enables smarter request batching and pacing.

Designing centralized connection pooling, request prioritization, and backoff mechanisms helps maintain stability across multiple strategies and reduces the likelihood of rate-limit breaches.

Implementing exponential backoff using exact reset times from headers and caching static data ensures continuous, reliable trading without overloading the exchange infrastructure.

Quick Checklist: What to Inspect and Change Right Now

Before touching strategy code, run through the connection layer. Most rate-limit failures trace back to a handful of fixable habits, not exchange bugs.

Read the headers. Every response from a well-documented exchange carries fields for the limit, what’s remaining, and when the counter resets. Ignoring these is the single most common mistake in retail bot code.
Identify the counting method. Some limits track by IP address, others by API key or account UID, and some by individual endpoint. Knowing which applies changes how you distribute requests.
Move polling to WebSocket. If you’re pulling order books or ticker data every second over REST, you’re burning quota you don’t need to spend.
Throttle low-priority calls. Balance checks and historical data pulls can wait. Order placement cannot.
Add exponential backoff with jitter, and track your 429 error rate as a standing metric, not an afterthought.

Handling these five items resolves the majority of rate-limit incidents developers report on exchange support forums.

How Exchanges Implement Rate Limits: Weights, Windows, and Counters

Exchanges rarely apply one flat rule. Most split limits into three tiers, and each tier behaves differently under load.

Public endpoints (order books, tickers, trade history) are usually capped by IP address, because anyone can call them without authentication. These limits tend to be the strictest, since a single IP can represent thousands of anonymous callers.
Private endpoints (balances, account status, open orders) are tied to your API key or account UID instead of your IP. Gemini, for example, documents a public limit of 120 requests per minute (roughly one per second) alongside a private limit of 600 requests per minute for authenticated calls, about five per second.
Trading endpoints (placing, modifying, canceling orders) often run on a separate counter entirely, because order flow has different risk implications for market integrity than a data lookup does.

Not every request costs the same amount of quota. Kraken and similar platforms assign point values to trading calls, so a batch cancel might cost more than a single order placement, and those points replenish over time rather than resetting all at once. This is the token-bucket model: you get a pool of points, spend them as you call, and watch them refill on a schedule, in contrast to a fixed window that snaps the counter back to zero at a set interval. Understanding which model an exchange uses tells you whether to smooth your request pattern or batch it.

Representative Exchange Rules: Gemini, Kraken, KuCoin, and Etherscan

Documentation varies by exchange, but the patterns repeat enough that once you understand one, the rest are variations on a theme.

Gemini recommends staying at or below one request per second on public endpoints and five per second on private ones, and it queues five extra requests as a burst buffer before returning a 429 error to anything beyond that.
Kraken separates its counters into public, private, and trading categories, with trading limits calculated per account and per currency pair, so a bot trading five pairs simultaneously has more effective headroom than one hammering a single pair.
KuCoin uses resource pools tied to VIP tier, meaning higher-volume accounts get larger quotas automatically, and its API responses include explicit headers, gw-ratelimit-limit, gw-ratelimit-remaining, and gw-ratelimit-reset, that tell your client exactly how much room is left and when it refreshes.
Etherscan, used heavily by bots that verify on-chain settlement, runs a simpler model: a fixed number of calls per second and a daily quota, with no weighting system to reason about.

When a response header gives you a countdown in milliseconds until the quota resets, that number is more reliable than any fixed sleep timer you could hard-code. Read it and act on it.

The header names differ across platforms, but the underlying signal is the same: the exchange is telling you exactly how close you are to the edge before you go over.

Engineering Patterns That Keep Automated Trading Reliable

The mitigation playbook for rate limits is not exotic. It’s a short list of habits that, applied consistently, keep a bot running through volatile sessions instead of stalling out of them.

Default to WebSocket for market data. REST polling for prices is the fastest way to burn IP-based quota, and exchange documentation consistently recommends streaming connections for anything data-intensive. Reserve REST calls for state queries that WebSocket doesn’t cover.
Honor the headers, always. When a response includes a retry-after value, use it. Ignoring it and retrying aggressively is the fastest route to a temporary ban, not just a rejected request.
Cache what doesn’t change every second. Exchange metadata, trading pair rules, and fee schedules don’t need a fresh call each cycle.
Queue requests by priority. Order placement and cancellation should never wait behind a balance check in the same queue.
Design order logic around unfilled-order counters, not raw call counts. Binance tracks only unfilled orders against its ORDERS limit, and each fill decrements that counter, which means a strategy that fills quickly can keep placing new orders even under a tight nominal limit.
Instrument your 429 rate as a first-class metric. A rising trend in rejected requests is an early warning that your request pattern needs adjustment before it becomes a trading outage.

Pro Tip: Build your backoff logic to read the exact reset time from the header rather than using a flat delay. A fixed two-second sleep either wastes time when the window resets sooner or gets you rejected again when it resets later.

Distributing load across permitted subaccounts or multiple API keys can raise effective throughput, but check the exchange’s terms first. This technique for managing API key permissions and IP restrictions only works within the rules the exchange actually allows.

How Integration Design Reduces Rate-Limit Friction

An trading automation platform that manages multiple exchange connections faces the same constraints an individual developer does, just multiplied across more accounts and strategies running at once. The engineering answer is structural rather than clever: centralize the connection layer so no single strategy can consume the entire request budget.

Connection pooling shares a limited number of authenticated sessions across strategies instead of opening a new connection per bot instance.
Centralized throttling applies one rate governor across all outbound calls for an account, so strategies don’t compete against each other for the same quota.
Request prioritization puts order placement ahead of analytics polling in the queue, matching the priority pattern developers should apply to their own code.
Paper trading and staging environments let a strategy’s request pattern get validated before it runs against a live account, catching a polling loop that’s too aggressive before it costs real quota, a practice covered in more depth in Darkbot’s guide to exchange integration.

Simplicity vs. Throughput: The Real Trade-Off for Bot Designers

Most retail bots don’t need distributed architecture. A single WebSocket connection with disciplined REST use for order management handles the overwhelming majority of strategies without ever approaching a limit.

The decision to add complexity, multiple keys, subaccounts, custom queuing, should follow a rate-limit problem you’ve actually measured, not one you’re anticipating. Higher account tiers or additional keys buy headroom, but engineering effort to use that headroom well often matters more than the headroom itself. A WebSocket-first design cuts REST pressure at the source, which tends to solve the reliability problem before throughput ever becomes the bottleneck.

— Grisha

How Darkbot Handles Exchange Connections for You

The platform is built around the same discipline this article describes: systematic request management instead of ad hoc polling. The platform centralizes exchange API key integration, connection pooling, and strategy pacing across supported exchanges, so individual bots don’t compete against each other for the same quota or trigger avoidable 429 responses.

Rather than writing and maintaining your own backoff logic, header parsing, and WebSocket failover for every exchange you connect to, The platform handles that layer as part of its automated trading infrastructure, paired with real-time analytics and risk controls that operate independently of any single connection’s throughput. If you want to see how an integrated platform manages exchange pacing rather than leaving it to custom scripts, you can start with Darkbot’s trading platform and review how strategy execution connects to your exchange accounts.

Authoritative Docs and Standards to Consult Next

For rule specifics, always defer to the exchange’s own documentation over third-party summaries, since limits change without much notice.

Exchange-specific pages: Gemini, Kraken, and KuCoin
Security standards: OWASP’s API Security guidance on unrestricted resource consumption
Comparing exchange documentation across platforms: Savings Grove’s exchange comparison

Sources

FAQ

What is a good API rate limit?

There’s no universal number. A good limit is one that lets your application accomplish its task without triggering 429 errors, which is why exchanges like Gemini publish separate recommended thresholds (roughly one request per second for public data, five per second for private calls) rather than one flat figure.

How do I fix “API rate limit exceeded”?

Read the response headers to find the reset time, pause requests until that window passes, then resume with exponential backoff rather than an immediate retry. Repeated aggressive retries after a 429 often extend the penalty or trigger a temporary ban.

How do I deal with API rate limits generally?

Shift high-frequency data needs to WebSocket, cache anything that doesn’t change every second, and queue requests by priority so order placement never waits behind routine polling. Tools like Darkbot’s connection pooling apply this same logic at the platform level.

What is the Binance API rate limit?

Binance uses separate counters for general request weight and for order-specific limits, and its ORDERS counter tracks only unfilled orders, meaning each fill decrements the count and allows further new orders even under a tight limit. Exact figures vary by endpoint and account tier, so check Binance’s own documentation for current values.

Does using WebSocket instead of REST actually reduce rate-limit issues?

Yes. WebSocket connections stream updates without repeated polling calls, which removes the IP-based REST pressure that causes most rate-limit rejections on market-data endpoints.