API trading connects your trading algorithms to broker or exchange servers so orders and market data flow automatically. In India, popular retail broker APIs such as Zerodha Kite, Upstox, and small institutional gateways have clear limits to protect their systems and other users. When you exceed those limits, servers respond with a 429 Too Many Requests error. This short friendly article explains what rate limits are, why 429 happens, and practical steps to prevent it in an Indian trading setup.
APIs use rate limits to cap how many requests a client can make in a time window. Limits may apply per minute, per second, per account, or per IP. Some services allow short bursts followed by cooldowns, while others enforce a strict steady rate. In trading, hitting a limit can mean missed price updates, failed order placements, or delayed cancels — all risky when markets move fast.
Common reasons you see 429 errors
- Polling too frequently for market data or order status.
- Opening too many simultaneous connections or sockets.
- Running many bots or scripts with the same API credentials.
- Not handling retry headers and backoff rules sent by the API.
- Using public shared environments (cloud instances) that aggregate requests from several services.
How rate limits look in practice
Some brokers allow, for example, 100 requests per minute per account, or 10 requests per second for market feeds. If you repeatedly hit those numbers, you’ll get 429. Exchanges also enforce quotas for historical or depth data. Understand these numbers for each API you use and plan accordingly.
Practical ways to avoid 429 errors in your trading setup
Handling a 429 when it happens
1. Read response headers. If a Retry-After header is present, pause for that duration.
2. Stop aggressive retries. Rapid retries can worsen the problem.
3. Log context (endpoint, payload, timestamp, account) to find which call pattern triggered the limit.
4. Backfill using cached data or delayed processing where real-time response isn’t critical.
Design considerations for Indian market hours and costs
Mumbai stock market hours (NSE/BSE) are fixed and intense between 9:15 AM and 3:30 PM IST. Design your polling cadence to be gentler outside market hours and more careful during auctions or opening/closing minutes. If API usage is charged — for example a premium data feed costing a few thousand rupees per month — efficient use reduces recurring costs. Also, be mindful of exchange levies and broker-specific limits during high-volatility events when many users hit the system.
Advanced approaches for reliability
- Use websocket streams for order updates and market ticks, falling back to REST only for rare calls.
- Implement a token bucket or leaky bucket algorithm in your client for smooth request pacing.
- Separate critical order flows from non-critical analytics: give orders highest priority so nonessential calls don’t interfere during bursts.
- If possible, request higher limits from your broker (often available for institutional clients) and negotiate SLAs in rupees if you need guaranteed throughput.
Final thoughts
429 errors are a signal to rework how your system interacts with an API, not a nuisance to be brute-forced away. Respect published limits, implement intelligent backoff and caching, and prioritise critical trading actions. In India’s brokerage ecosystem, a small investment in robust rate-limit handling can reduce missed trades, lower costs, and make your algo trading more reliable during volatile sessions.
APIs use rate limits to cap how many requests a client can make in a time window. Limits may apply per minute, per second, per account, or per IP. Some services allow short bursts followed by cooldowns, while others enforce a strict steady rate. In trading, hitting a limit can mean missed price updates, failed order placements, or delayed cancels — all risky when markets move fast.
Common reasons you see 429 errors
- Polling too frequently for market data or order status.
- Opening too many simultaneous connections or sockets.
- Running many bots or scripts with the same API credentials.
- Not handling retry headers and backoff rules sent by the API.
- Using public shared environments (cloud instances) that aggregate requests from several services.
How rate limits look in practice
Some brokers allow, for example, 100 requests per minute per account, or 10 requests per second for market feeds. If you repeatedly hit those numbers, you’ll get 429. Exchanges also enforce quotas for historical or depth data. Understand these numbers for each API you use and plan accordingly.
Practical ways to avoid 429 errors in your trading setup
- Reduce polling: Instead of fetching every second, use websockets or streaming endpoints where available. Streams deliver updates as they happen and keep request counts low.
- Cache results: For data that changes slowly (e.g., instrument lists, static symbol meta), store it locally and refresh only when needed.
- Batch requests: Combine multiple small requests into fewer calls if the API supports batching.
- Use exponential backoff: On 429, wait and retry with increasing delays (for example, 1s, 2s, 4s). Respect the Retry-After header if present.
- Distribute load: If you run multiple bots, distribute API keys across them or coordinate so only one process polls common endpoints.
- Throttle client-side: Implement a local limiter that ensures you never exceed documented per-second or per-minute limits.
- Monitor and alert: Track rate-limit headers and create alerts when consumption nears thresholds.
Handling a 429 when it happens
1. Read response headers. If a Retry-After header is present, pause for that duration.
2. Stop aggressive retries. Rapid retries can worsen the problem.
3. Log context (endpoint, payload, timestamp, account) to find which call pattern triggered the limit.
4. Backfill using cached data or delayed processing where real-time response isn’t critical.
Design considerations for Indian market hours and costs
Mumbai stock market hours (NSE/BSE) are fixed and intense between 9:15 AM and 3:30 PM IST. Design your polling cadence to be gentler outside market hours and more careful during auctions or opening/closing minutes. If API usage is charged — for example a premium data feed costing a few thousand rupees per month — efficient use reduces recurring costs. Also, be mindful of exchange levies and broker-specific limits during high-volatility events when many users hit the system.
Advanced approaches for reliability
- Use websocket streams for order updates and market ticks, falling back to REST only for rare calls.
- Implement a token bucket or leaky bucket algorithm in your client for smooth request pacing.
- Separate critical order flows from non-critical analytics: give orders highest priority so nonessential calls don’t interfere during bursts.
- If possible, request higher limits from your broker (often available for institutional clients) and negotiate SLAs in rupees if you need guaranteed throughput.
Final thoughts
429 errors are a signal to rework how your system interacts with an API, not a nuisance to be brute-forced away. Respect published limits, implement intelligent backoff and caching, and prioritise critical trading actions. In India’s brokerage ecosystem, a small investment in robust rate-limit handling can reduce missed trades, lower costs, and make your algo trading more reliable during volatile sessions.