Persistent AB1021 rate-limit error on getCandleData despite low request rate

Jay Patel

I'm using SmartAPI's getCandleData (FIVE_MINUTE interval) for 12 NSE symbols.
Since ~09:15 IST on 2026-08-10 I've been getting AB1021 "Too many requests"
errors on most calls, continuously for 5+ hours, even after spacing my
requests 6-10 seconds apart (well under the documented 3 req/sec limit).

Affected window: 2026-08-10, 09:15 IST onward
Error: AB1021 "Too many requests"

This looks like an account-level throttle rather than a live rate-limit hit.
Could you please help check if any restriction is applied to my account?

saif859

@jay-patel A few checks from having debugged this exact error family recently:

Documented caps for getCandleData are 3/sec AND 180/min AND 5000/hr. Calls 6-10s apart sit well under all three — IF that's the only traffic on the key.
Caps are enforced server-side per client code, not per script. Usual silent breaches: a second process/notebook/cron on the same key; instant retries after an AB1021 (each retry counts and extends the throttle); or all 12 symbols fired near-simultaneously at the top of each cycle — that's a >3/sec burst even with 6-10s cycles. Log actual send timestamps, not the loop's sleep schedule.
If none apply, escalate with client code + exact timestamps — other threads this period report AB1021 below documented limits, and I hit the server cap on a modest backfill myself.

What works in production: client-side sliding-window limiter enforcing all three caps, exponential backoff on any AB1021, chunked backfills. For live 5-min candles on 12 symbols, consider building bars from the websocket instead of polling.

I do broker-API integration work — DM if you're stuck.

pari

Same issue here — running a Nifty-options intraday bot polling getCandleData (FIVE_MINUTE) once every 5 minutes, ~0.003 req/s against the documented 3 req/s/client cap. Comparing the identical 09:15-10:35 window across three consecutive sessions: 12, then 17, then 27 rate-limit rejections, and the last two days both fully exhausted a 6-attempt retry budget on the very first request of the day, before any other call had been made.

That makes six independent reports of this exact symptom now, across two different endpoints — candle data and order book — all well under documented limits: 5636/5637, 5611, 5625, 5595, 5560. I've put together a fuller writeup with the full data here: https://smartapi.angelbroking.com/smartapi/forum/topic/5639/getcandledata-rate-limit-false-positives-at-0-003-req-sec-six-independent-reports-zero-acknowledgment

Would genuinely appreciate an actual look at the server-side telemetry rather than another "can't help with your code" response.