Exchange API Rate Limits: A Trading Bot Survival Guide

An exchange API rate limit is a cap on how many requests your bot can send in a fixed window. Go over it and the exchange rejects your calls with a 429 error. Keep going and it can ban your IP address. For an automated trader, the limits decide whether a signal becomes a filled order or a silent miss.

This guide covers how the limits are measured, what the major exchanges publish, and how to design a TradingView-driven bot so it stays inside the lines. It also covers the second set of limits that many traders forget: the ones TradingView itself enforces before your signal ever reaches an exchange.

TL;DR

• Exchanges meter requests with weights, counters or token buckets, and they usually measure per IP address, per API key, or both. Know which one applies to each endpoint.
• A 429 means slow down now. Retrying immediately is how bots earn automated IP bans, and swapping API keys does not lift an IP-based ban.
• TradingView has its own caps (15 triggers per 3 minutes for a regular alert) and a webhook response window of about 3 seconds. Both are independent of exchange limits.
• The safest design sends only order-relevant calls, avoids polling, and spreads strategies across alerts so no single stream spikes.

Table of Contents

• What an exchange API rate limit actually measures
• What the major exchanges publish
• 429, 418 and the ban ladder
• The limits that sit before the exchange
• Designing a bot that stays inside the limits
• How the limits shape common strategy types
• Our perspective: speed and limits are one problem
• Automating TradingView alerts without managing the plumbing
• A pre-launch checklist
• FAQ
• Sources

What an exchange API rate limit actually measures

The simple definition is requests per time window. The real picture is more layered. Exchanges typically separate limits by:

• Endpoint type: public market data, private account queries, and order placement are metered separately.
• Identity: the limit may be tied to your IP address, your API key, your account, or a mix.
• Cost: some calls count as one request, others consume “weight” because they are heavier for the exchange to serve.
• Interface: REST, WebSocket and FIX connections often have different budgets.

The distinction between identity types matters most in practice. If limits are per IP, every bot you run from the same machine or cloud address shares one budget. If limits are per API key, a second key gets its own budget. Exchanges may also combine them, so reading the docs for each endpoint group is not optional.

Weights, counters and token buckets

Most exchanges use one of two mental models. In a weight system, each request consumes a number of points from a budget that resets or replenishes over a window. In a counter system, a number rises with each call and decays over time, and you are throttled when it crosses a maximum.

The bucket model has one trap. Burst allowances let you briefly exceed the steady refill rate, but if you operate at the burst ceiling continuously, the bucket drains and the 429s arrive even though your hourly average looks modest. Treat the burst figure as an emergency reserve, not as your working speed.

What the major exchanges publish

Numbers change, so confirm them on the exchange’s own page before you size a bot around them. Here is what the documentation says at the time of writing.

Two details deserve attention.

First, Binance tells you the current limits are queryable through its exchangeInfo request, and responses can include a rateLimits field showing your usage. A bot that reads this instead of hard-coding numbers survives limit changes.

Second, sub-accounts do not always multiply your budget. Kraken’s developer documentation says sub-accounts can have their own API keys but share the master account’s trading rate limit. Splitting strategies across sub-accounts helps with balance isolation, not necessarily with throughput.

429, 418 and the ban ladder

When you break a limit, the exchange tells you with an HTTP status code. The common ones for bot builders:

1. 429 (too many requests): you exceeded a limit. Stop, read any Retry-After or retryAfter value, and wait.
2. 418 (IP banned): you kept sending after 429s. On Binance, repeatedly violating limits or failing to back off after 429s results in an automated IP ban, and the ban applies to the address, not the key.
3. 403 (WAF limit): the web application firewall limit was violated, a separate protection layer described in Binance’s general info page.

The practical consequence: if your bot is banned by IP, creating a new API key changes nothing. The restriction follows the address, and your bot stays offline until the penalty expires. Bans are automated and the duration grows if you repeat the offense, so the cheapest fix is never to trigger one.

Backoff done right

Treat every 429 as a mandatory signal for exponential backoff, not an invitation to retry. A sound pattern:

1. On 429, pause all calls from that IP to that exchange, not just the failing one.
2. Honor the exchange’s retry hint if it provides one. Otherwise wait 1 second, then 2, then 4, up to a cap you choose.
3. Add random jitter so parallel workers do not retry in the same instant.
4. Resume at a lower rate than before and ramp up slowly.
5. Log every 429 with the endpoint and the weight you had consumed, so you can see which call pattern causes them.

Order placement deserves extra care. A blind retry after a timeout can create a duplicate order if the first request actually succeeded. Where the exchange supports client order IDs, use them so a retry is idempotent, and check order status before resending.

The limits that sit before the exchange

If your signals come from TradingView, you face a second layer of throttling that has nothing to do with your exchange. Traders often assume that because the exchange would accept the order, the alert will arrive. It may not.

TradingView alert caps

TradingView states that a regular alert can fire no more than 15 times in 3 minutes. Watchlist alerts have an overall cap of 1,000 triggers in 3 minutes for the entire list. Exceed the threshold and TradingView stops the alert automatically.

That is a silent failure mode. Your strategy keeps computing, the chart looks normal, and the alert simply stops delivering. Strategies that scale in and out on every tick, grid logic, or a noisy indicator on a one-minute chart are the usual culprits. If you run many instruments through one script, prediction-market and cross-venue data teams face the same alert-volume problems when streaming real-time signals, and the lesson transfers: cap the event rate at the source.

Practical fixes:

• Trigger on bar close instead of every tick where your logic allows it.
• Add cooldown conditions in Pine Script so one condition cannot fire repeatedly.
• Split heavy strategies across separate alerts rather than one stream.
• Send one alert message that carries the full instruction (entry, stop, target) instead of three alerts for one trade. On Tickerly, a full trade alert attaches the take profit and stop loss to the entry on Bybit, Binance, Oanda and Capital.com; our guide to full trade alerts shows the format.

If alert counts are the bottleneck rather than frequency, see how to get more usable TradingView alerts without upgrading your TradingView plan.

The 3-second webhook window

TradingView’s documentation on configuring webhook alerts describes a webhook as an HTTP POST sent to a URL you provide. The receiving server has to answer quickly: the practical window is about 3 seconds. If your endpoint is slow, overloaded or cold-starting, the request is cancelled and the signal never becomes an order, even if no exchange limit was ever touched.

This is an infrastructure question, not a rate-limit one, but the symptom looks the same: a missing fill. Fast acknowledgment matters, and so does everything on your side of the chain, including the hardware and workflow you use to act on signals manually when automation hands control back to you. A good bot acknowledges the webhook immediately and processes the order afterward.

Designing a bot that stays inside the limits

Here is a working checklist, from most to least impactful.

1. Prefer push over poll

Polling order status every second burns budget for no benefit. Use WebSocket streams for fills and balance updates where the exchange offers them, and keep REST for placing and cancelling. Remember that connection counts are limited too: Binance caps connection attempts per IP, so a reconnect loop with no delay can cause its own ban.

2. Budget by weight, not by request count

List every call your bot makes per signal: balance check, position check, order, order confirmation. Add up the weight for a worst-case burst, such as ten strategies firing on the same candle close. If that number approaches the limit, remove calls you can infer instead of fetch.

3. Know your identity boundaries

Write down for each exchange whether limits are per IP, per key or per account. Then decide deliberately:

• Many strategies on one account usually share the order budget.
• Many bots on one server share the IP budget.
• Separate keys help only where the limit is per key.

4. Reduce redundant orders

Exchanges set limits on order placement and cancellation partly to prevent order-book manipulation, as Kraken notes. Cancel-and-replace loops that chase price are the fastest way to consume that budget. Use limit orders with sensible tolerance, or market orders when speed outweighs price, rather than constantly amending.

5. Add a queue and a circuit breaker

Put a small queue between incoming signals and exchange calls. When a 429 arrives, the breaker opens, the queue holds orders, and the bot resumes at a slower pace. Decide in advance which orders matter most: a stop-loss or close should jump ahead of a new entry.

6. Test with realistic bursts

Backtesting tells you whether the strategy has an edge. It does not tell you whether your infrastructure survives twenty signals in one second. Replay a burst of alerts into a test or paper environment and watch your counters. Our alert log test page is a useful place to confirm alerts are reaching their destination.

How the limits shape common strategy types

Grid logic is the clearest example. A grid can place dozens of orders from a single price move, and TradingView’s 15-in-3-minutes cap arrives well before the exchange’s. If you run one, read how to convert TradingView grid alerts to live orders without a bridge.

Our perspective: speed and limits are one problem

Traders usually frame speed and rate limits as opposites: go faster and you hit the ceiling. We see them as the same engineering problem. The fastest bot is the one that wastes no calls.

Tickerly is built around turning TradingView alerts into live orders within a fraction of a second, which is the reason we care about this topic. Speed only matters if the order arrives, and an order arrives only if the alert was not throttled, the webhook was acknowledged, and the exchange call stayed inside its limit. When an expected trade never appears, check those three links before you question the strategy logic.

So our advice is blunt. Design the alert first: one clear message per trade decision, with a cooldown, on a bar-close trigger where your edge allows it. Keep exchange calls to what the order requires. Use no-code automation so you are not maintaining a VPS and a custom server whose response time you must keep under TradingView’s window. And monitor, because a limit you never see is a limit you never fix.

Limits are not an obstacle to automation. They are the spec your bot has to meet.

— Jay

Automating TradingView alerts without managing the plumbing

If you would rather not build the webhook receiver and the exchange connectors yourself, Tickerly converts your TradingView strategy alerts into live orders across crypto, forex, stocks and futures with no coding, and with no VPS for direct exchange connections. MetaTrader 4 and 5 are supported too, through the Tickerly TV Connector in your own terminal, which has to stay running. Binance and Kraken are among the supported exchanges; Coinbase is not. Every plan starts with a 30-day free trial. Published plans run from Level 2 at 19 USD per month, Level 3 at 29 USD per month and Level 4 at 39 USD per month, up to Level 4 Ultra for 2,500 alerts a day. Each plan has a daily alert allowance (100 on Level 2, 1,000 on Level 3 and 4), so check it against your worst-case signal count, the same way you would an exchange limit. Compare them on the automated trading plans page, or read the walkthrough on going from alert to live order.

A pre-launch checklist

Before you put real capital behind a strategy, confirm each item:

• You have read the current rate-limit page for every exchange you trade on, and noted whether each limit is per IP, key or account.
• Your worst-case burst, with all strategies firing at once, fits inside the budget.
• No alert can fire more than 15 times in 3 minutes under normal market conditions.
• If you run your own receiver, it acknowledges within the 3-second window, honors 429 responses with exponential backoff and jitter, and puts closing and stop orders ahead of new entries in its queue.
• You review errors weekly: rate-limit headers and errors in your own bot’s logs, or on Tickerly the exchange’s rejection messages in the alert log and your notifications.

FAQ

What happens if my trading bot exceeds an exchange rate limit?

The exchange rejects further requests, usually with an HTTP 429 response. If the bot keeps sending without backing off, the exchange can escalate to an automated IP ban, as Binance documents. During a ban your bot cannot place or cancel orders, so open positions go unmanaged.

Does a new API key fix a rate-limit ban?

Not if the ban is IP-based. Binance tracks its automated bans per IP address, so a new key from the same address stays locked out until the penalty ends. Some limits, such as Kraken’s private-endpoint counter, are tracked per API key, so check which model applies.

Are TradingView alert limits the same as exchange API limits?

No. They are separate. TradingView stops a regular alert that triggers more than 15 times in 3 minutes, whatever the exchange would accept. You need to stay inside both sets of limits.

How fast must my webhook server respond to TradingView?

TradingView’s guidance is that the server should respond within about 3 seconds. A slower response cancels the request, and the signal is lost. Acknowledge the alert first and place the order afterward.

Where do I find the current limits for an exchange?

Use the exchange’s official documentation, since numbers change. Coinbase publishes them in its Exchange rate limits overview, Kraken on its support page, and Binance in its API docs, where the exchangeInfo request returns the live values.

Sources

• Coinbase Exchange rate limits overview
• Binance Spot WebSocket API rate limits
• Binance Open Platform general info
• Kraken: What are the API rate limits?
• Kraken sub-accounts and multi-account management
• TradingView: Alert was triggered too often and stopped
• TradingView: How to configure webhook alerts

Recommended

• Bot Trading Liquidity Factors: Design Bots That Survive
• How Trading Bots Respond to Market Volatility
• Trading Bot Strategy – The 5 Essential Elements Every Bot Needs
• Trading Bot Crypto: Complete Guide to Automation 2026

This article was produced with Al assistance and reviewed for accuracy. It is provided for general information only and is not professional or financial advice.