getCandleData (Historical API) returning HTTP 403 "Access denied because of exceeding access rate" — even on minimal requests


  • Issue:

    The API worked correctly yesterday (3-Sep-2026).
    Today (4-Sep-2026), every call to getCandleData returns: HTTP 403 - "Access denied because of exceeding access rate"
    This happens even on a test with only 5 symbols, spaced well under 1 request/second, with no other calls running in parallel.
    Login (loginByPassword) and live quotes (market/v1/quote) both succeed normally — only the historical data endpoint is rejected.
    Suspect this may be a temporary account-level throttle/block triggered by repeated testing earlier today, rather than a real-time rate limit, since even trivial request volumes are still being rejected.


  • Same issue here. Single getCandleData call once per hour, MCX commodity, ONE_HOUR, ~495 candles. Roughly one cycle in three rejected with plain-text Access denied because of exceeding access rate.

    One data point that may help narrow it: on 4 Sep, three attempts spaced 75 seconds apart (13:02:30, 13:03:45, 13:05:00) were all rejected — so the block persisted over 2.5 minutes, which doesn't look like a short-window burst limit.

    Also noticing that the Python SDK sets X-ClientPublicIP to an address that isn't the static IP registered against my app, though requests do originate from the registered IP. Has anyone checked whether that's related?


  • In my case, after login succeeded, the very first call itself is failing with "Access denied because of exceeding access rate" error. This is happening for https://apiconnect.angelone.in/rest/secure/angelbroking/historical/v1/getCandleData API. Lately, the calls to this API is throwing the rate limit error most of the time for me, even though it is the only call made after login from my account.

    AngelOne SmartAPI Team - You have some serious issue here to fix. This is affecting lot of people. Your rate Limiting logic has major bugs to be fixed.

    One to fix this issue: You can cache the candle data, so that you don't need to build the response for every calls. This should drastically reduce your server over load.