getCandleData rate-limit false positives at ~0.003 req/sec — six independent reports, zero acknowledgment

[pari]

I'm running an automated Nifty-options intraday strategy that polls getCandleData (FIVE_MINUTE interval) once every 5 minutes — a single index token, no other endpoints hit concurrently. That's roughly 0.0033 requests/second, against the documented cap of 3 requests/second/client. We are nowhere close to any published limit — by a factor of ~900x — and we still get hit with: DataException: Couldn't parse the JSON response received from the server: b'Access denied because of exceeding access rate'

The trend is getting worse, not better. Comparing the identical 09:15-10:35 window across three consecutive trading sessions, same code, same request pattern, one call every 5 minutes throughout: on 2026-08-10 there were 12 rate-limit rejections and startup seeding succeeded without a struggle. On 2026-08-11 that jumped to 17 rejections, and startup seeding fully exhausted its 6-attempt retry budget over roughly 56 seconds, every attempt rejected. On 2026-08-13 it jumped again to 27 rejections, with the exact same full-exhaustion pattern at startup.

On both of the last two sessions, the very first request of the day — before a single other call had been made — was rejected, and it took the full retry budget just to get through initial startup. This isn't a burst-traffic problem on our end; it's the first request of a cold session hitting a wall.

This is not an isolated report. The same symptom — well-under-limit requests rejected with this exact rate-limit error — has been independently reported at least six times on this forum, across two different endpoints (getCandleData and getOrderBook). Topic 5636 (https://smartapi.angelbroking.com/smartapi/forum/topic/5636/persistent-ab1021-rate-limit-error-on-getcandledata-despite-low-request-rate/2) and 5637 (https://smartapi.angelbroking.com/smartapi/forum/topic/5637/persistent-ab1021-rate-limit-error-on-getcandledata-despite-low-request-rate) show the same symptom on FIVE_MINUTE getCandleData, including a report of failure on the very first call of a fresh day. Topic 5611 (https://smartapi.angelbroking.com/smartapi/forum/topic/5611/persistent-ab1021-too-many-requests-on-getcandledata-nse-well-below-limit/2) reports the same symptom at 1 request per 5-6 seconds, and notes that NSE fails while MCX — same script, same IP — works fine all day. Topic 5625 (https://smartapi.angelbroking.com/smartapi/forum/topic/5625/ag8004-invalid-api-key-on-getcandledata-getltpdata-login-works-fine) reports a related failure mode, AG8004 "Invalid API Key," on the same endpoints, while login and profile calls work fine with the same key. Topic 5595 (https://smartapi.angelbroking.com/smartapi/forum/topic/5595/smartapi-smartexceptions-dataexception-couldn-t-parse-the-json-response-received-from-the-server-b-access-denied-because-of-exceeding-access-rate/4) reports this exact error message, verbatim. Topic 5560 (https://smartapi.angelbroking.com/smartapi/forum/topic/5560/api-rate-limit-checks-are-not-perfect) reports the same rejection on a completely different endpoint, Order Book, ruling out anything specific to historical or candle data.

And the response so far has been to not engage with it. The one visible staff reply across all of these, on topic 5595, was: "Unfortunately, we cannot help you in the debugging / improvement of the code." — with no acknowledgment that six independent users, on two different endpoints, all reporting request rates an order of magnitude or more under documented limits, might point to something on the server side rather than six unrelated coding mistakes. Multiple of these threads (5637, 5595, 5560) now show as deleted, with no resolution ever posted.

I'm not asking for a workaround — we already have client-side retry/backoff absorbing this. I'm asking for someone from AngelOne to actually look at the server-side rate-limit telemetry for accounts reporting this, and either confirm it's a known issue or explain what we're missing. Silence and thread deletion isn't a fix.

[pari]

@admin Tagging you directly for visibility — six independent reports of this exact symptom, across two different endpoints, all well under documented limits, deserves more than the one dismissive reply on topic 5595. Could someone actually look at the server-side rate-limit telemetry for the accounts involved (linked above) and confirm whether this is a known issue?