Home / APIs & Automation / Rate Limits
ThrottlingIntermediate

Rate Limits

A rate limit is a broker-imposed cap on how many API requests you may send within a time window, enforced to protect their infrastructure, and exceeding it triggers throttling, 429 errors or temporary bans.

Quick answer: A rate limit is a broker-imposed cap on how many API requests you may send within a time window, enforced to protect their infrastructure, and exceeding it triggers throttling, 429 errors or temporary bans.

In simple words

A rate limit is a speed limit on your API calls. The broker allows only so many requests per second or per minute, and if you go faster they start rejecting your requests or block you for a while. Your code has to pace itself, because tripping the limit at the wrong moment can mean a missed order.

Purpose

Rate limits exist so one client cannot overwhelm the broker's servers and degrade service for everyone; respecting them keeps your access stable and your critical order requests from being throttled when you need them.

Professional explanation

How rate limits are expressed

Brokers publish limits in several shapes, and you must design to the actual one. Common forms are requests-per-second, requests-per-minute, and separate quotas per endpoint category — order placement often has a tighter limit than data reads. Some APIs also cap concurrent connections or the number of instruments per WebSocket. A key subtlety is the enforcement window: a limit of 10 requests per second might be a rolling window (any 1-second span) or a fixed window (each calendar second reset), and bursting behaves very differently under each. Read the documentation for both the number and the window, because guessing leads to intermittent, hard-to-reproduce 429s.

The 429 response and Retry-After

When you exceed a limit, a well-behaved API returns HTTP 429 Too Many Requests, often with a Retry-After header telling you how long to wait. The correct response is to stop, honour the wait, and only then retry — not to immediately re-send, which digs the hole deeper and can escalate to a temporary ban. Because 429 is a transient condition, it belongs in your retry-with-backoff path, but distinctly from 5xx: a 429 specifically means slow down, whereas a 500 means the server erred. Ignoring Retry-After and retrying aggressively is a fast route to being blocked.

Client-side throttling: staying under the ceiling

The robust approach is to never hit the limit in the first place by throttling yourself. A common mechanism is a token-bucket or leaky-bucket rate limiter: the bucket refills at the allowed rate, each request consumes a token, and if the bucket is empty the request waits. This smooths bursts into a steady stream that stays below the ceiling. Placing this limiter inside your shared API client means every part of the system automatically respects the budget, and you tune it to a safe margin below the published limit rather than riding the exact edge, since clocks and windows never align perfectly.

Batching and reducing request count

Often the best way to respect a limit is to need fewer requests. Many broker APIs offer batch or bulk endpoints — fetching quotes for many instruments in one call, or querying the full order book rather than each order individually. Subscribing to a WebSocket instead of polling REST for prices collapses thousands of would-be requests into one connection. Caching data that changes slowly — the instrument master, margins — avoids re-fetching it in a loop. Every request you design out of the system is a request that can never trip the limit.

Prioritising critical requests

Not all requests are equal: placing or cancelling an order matters far more than refreshing a dashboard. Under a shared budget, low-priority polling can starve high-priority order actions right when the market moves. Mature systems therefore reserve headroom for order flow — for instance, a separate limiter or a priority queue that lets a cancel jump ahead of a routine quote refresh. The design goal is that you never fail to cancel a runaway position because a background task consumed the quota.

Consequences of ignoring limits

Persistently breaching rate limits escalates. First requests get 429s; then the broker may impose a temporary ban of minutes to hours; repeated abuse can lead to key suspension. During a ban your system is effectively blind and unable to act — a dangerous state if you hold open positions. Because the penalty lands precisely when you are behaving badly, and markets do not pause for your timeout, treating rate limits as a hard engineering constraint rather than a soft suggestion is a risk-management issue, not merely a courtesy to the broker.

Ways to stay within rate limits

TechniqueWhat it doesBest for
Client-side throttlePaces requests below the capAll request types
BatchingMany items per requestBulk quotes / status
WebSocket streamingOne connection vs pollingLive market data
CachingAvoids re-fetching stable dataInstrument master, margins
Priority reservationProtects order requestsCritical order flow

Practical example

Illustrative example (Indian market)

Suppose a broker allows 3 order requests per second and 10 data requests per second. Your system tracks 200 instruments. Instead of polling each with its own request (which would need far more than 10/second), it subscribes to one WebSocket for prices and uses a batch quote endpoint for snapshots, staying at about 2 data requests per second. A token-bucket limiter in the API client caps order placement at 2 per second — deliberately below 3 — reserving margin. When a burst of signals arrives, orders queue through the limiter rather than firing all at once and earning a 429. The numbers are illustrative.

Indian broker APIs commonly separate quotas — for example a modest orders-per-second cap alongside a higher data-request cap — and enforce them per API key. If you run several strategies on one key they share the same budget, so a chatty research script can throttle your live order flow. Isolating critical execution behind its own reserved budget prevents that collision.

Advantages

  • Respecting limits keeps your access stable and avoids disruptive bans
  • Client-side throttling makes request load predictable and smooth
  • Batching and streaming cut request counts, improving both limits and latency
  • Reserving budget for orders ensures critical actions are not starved by background tasks

Limitations

  • Limits constrain how frequently you can poll or act, which some strategies must design around
  • Windows and enforcement differ per broker and endpoint, so tuning is broker-specific
  • A shared key means one component's requests can throttle another's
  • Under a ban your system is blind and cannot act, which is dangerous with open positions
  • Published limits can change, silently breaking a system tuned to the old ceiling

Common mistakes

  • Retrying immediately after a 429 instead of honouring Retry-After and backing off
  • Polling REST endpoints in a tight loop instead of using a WebSocket or batch call
  • Riding the exact published limit with no safety margin for clock and window drift
  • Letting a background or research task share the order-flow budget and starve real orders
  • Ignoring per-endpoint limits and assuming one global quota covers everything
  • Not caching slow-changing data like the instrument master, re-fetching it every cycle

Professional usage

Professional clients embed a rate limiter (token or leaky bucket) at the transport layer so every request across the system is automatically paced below the published cap. They separate budgets by priority, reserving headroom for order placement and cancellation, and they prefer batch endpoints and streaming over polling to minimise request count. 429s and Retry-After headers feed the backoff logic, and limit breaches are monitored as an early warning that something is misbehaving before a ban lands.

Key takeaways

  • A rate limit caps requests per time window; exceeding it yields 429s, throttling or bans
  • Throttle yourself client-side with a token/leaky bucket, tuned below the published ceiling
  • Reduce requests by batching, streaming and caching instead of polling in loops
  • Reserve budget for critical order flow, and honour Retry-After rather than hammering after a 429

Frequently asked questions

What is an API rate limit?
It is a cap on how many requests you may send within a time window, set by the broker to protect their servers. Exceeding it triggers 429 errors, throttling or temporary bans, so your client must pace its requests to stay under the cap.
What does a 429 error mean?
HTTP 429 Too Many Requests means you exceeded the rate limit. Often it includes a Retry-After header telling you how long to wait. The correct response is to stop, wait the indicated time, and only then retry — not to re-send immediately.
How do I avoid hitting rate limits?
Throttle yourself with a token- or leaky-bucket limiter tuned below the published cap, batch requests where the API allows, use a WebSocket for live prices instead of polling, and cache slow-changing data. The goal is to need fewer requests and pace the ones you send.
What is a token-bucket rate limiter?
It is a mechanism where a bucket refills tokens at the allowed rate and each request consumes one; if the bucket is empty, the request waits. This smooths bursts into a steady stream that stays below the limit, and it lives inside your shared API client.
Do order and data requests share the same limit?
Often not. Many brokers set a tighter cap on order placement than on data reads, enforced per category. You must design to each endpoint's specific limit rather than assuming a single global quota covers everything.
What happens if I keep exceeding the limit?
It escalates: first 429 rejections, then a temporary ban of minutes to hours, and with repeated abuse possible key suspension. During a ban your system cannot act, which is dangerous if you hold open positions.
Should I retry immediately after a 429?
No. Honour the Retry-After header (or back off) before retrying, because re-sending immediately deepens the breach and can trigger a ban. A 429 specifically means slow down, distinct from a 5xx which means the server erred.
How does batching help with rate limits?
Batch endpoints let you fetch many items — quotes for many instruments, or the whole order book — in one request instead of many. Fewer requests means less pressure on your quota and often lower latency too.
Can polling for prices trip the rate limit?
Easily. Polling each instrument in a loop generates a request per instrument per cycle, which quickly exceeds data quotas. Subscribing to a WebSocket collapses that into one persistent connection and is the correct pattern for live prices.
Why reserve budget for order requests?
Because a background or research task sharing the same quota can consume it and starve order placement or cancellation right when the market moves. Reserving headroom or a separate limiter for order flow keeps critical actions available.
Are rate limits the same across brokers?
No. The numbers, windows and per-endpoint structure differ by broker and can change with API versions. Always read the current documentation and tune your throttling to that specific broker's published limits.
Do multiple strategies on one key share a limit?
Yes, if they use the same API key they draw on the same quota. A chatty script can then throttle your live orders. Isolating critical execution behind its own reserved budget, or a separate key where allowed, avoids the collision.

Voice search & related questions

Natural-language questions people ask about Rate Limits.

What is a rate limit on a trading API?
It is a speed limit on how many requests you can send. Go too fast and the broker rejects your calls or blocks you for a while, so your code has to pace itself.
What should I do when I get a 429 error?
Stop and wait the time the Retry-After header says, then try again. Re-sending immediately just makes it worse and can get you banned.
How do I stop hitting the rate limit?
Pace your requests with a throttle, batch calls together, use a WebSocket for live prices, and cache data that rarely changes. Fewer, slower requests stay safe.
Why not just poll prices as fast as possible?
Because it burns through your request quota and trips the limit. A WebSocket streams prices on one connection without eating your quota.
Can hitting rate limits get me banned?
Yes. Keep breaching them and the broker can block you for minutes, hours, or suspend the key. That is dangerous when you hold open positions.
Do my orders and data share the same limit?
Often not — orders usually have a tighter cap than data reads. Reserve room for order requests so background tasks do not use up your order budget.

Sources & references

    Last reviewed 11 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.

    ← Previous
    Authentication
    Educational content only — not investment advice. Examples use illustrative numbers and simplified models. Algorithmic trading and derivatives involve substantial risk. See our Risk Disclosure and SEBI Disclaimer.