Date: 23 October 2026
API: Angel One SmartAPI — getCandleData
Instrument: Nifty 50
Application: VPAUL888
Trading mode: Dry-run only; no live orders placed

1. My experience

I am developing a Python-based Nifty options trading bot using Angel One SmartAPI. The bot logs in successfully, but I am repeatedly encountering the following error while retrieving historical candle data:

Access denied because of exceeding access rate

I have implemented candle-data caching, a minimum 20-second gap between requests, and exponential backoff after failures. Despite these precautions, the same error keeps recurring.

2. What Angel One Support told me

In a response from Angel One SmartAPI Support, I was informed that:

• The getCandleData limit had been reduced from 150 to 120 requests per minute.
• The other stated limits remained unchanged: 3 requests per second and 5,000 requests per hour.
• Errors may occur during peak traffic when the overall API limit is reached.
• A retry mechanism with exponential backoff was recommended.

Documentation provided by support: https://smartapi.angelbroking.com/docs/RateLimit

I appreciate the clarification, but my practical issue remains unresolved.

3. Actual bot logs — 23 October 2026

The following are excerpts from my actual application logs:

2026-10-23 12:21:46,271 INFO: Starting NIFTY bot in DRY-RUN mode. LIVE_TRADING=False
2026-10-23 12:21:46,559 INFO: Angel One login successful. LIVE_TRADING=False
2026-10-23 12:21:48,465 INFO: Fetched 38 candle rows for Nifty 50 (99926000).

2026-10-23 12:25:48,631 WARNING: Candle request error: Couldn't parse the JSON response received from the server: b'Access denied because of exceeding access rate'; waiting 900s.

2026-10-23 12:40:48,808 WARNING: Candle request error: Couldn't parse the JSON response received from the server: b'Access denied because of exceeding access rate'; waiting 1800s.

2026-10-23 13:08:50,676 WARNING: Candle cooldown active: 119s remaining.

After the first rate-limit error, the bot waited 900 seconds before retrying. The next request again received the same error, so the cooldown increased to 1,800 seconds.

The bot was waiting through the cooldown when the last excerpt above was recorded.

4. Why this concerns me

My concern is not simply that an API request occasionally fails. It is that the candle-data feed remains unavailable to my application after I have introduced request throttling, caching, and backoff.

My strategy requires sufficient historical candle data before its signals can be evaluated. The initial response returned only 38 candle rows, while my strategy requires at least 55. As a result, I have not been able to complete proper validation of the strategy.

I am keeping LIVE_TRADING=False throughout testing. These logs do not represent live trades or financial losses.

5. Questions for the community and Angel One

1. Has anyone else experienced repeated getCandleData rate-limit errors despite conservative request spacing and exponential backoff?
2. Does the stated limit apply per API key, application, client account, IP address, or through a broader shared limit?
3. Is the “exceeding access rate” message also returned during periods of wider API congestion?
4. What is the recommended way to retrieve sufficient historical candles and then poll new candles reliably?
5. Has anyone received a technical explanation or a permanent resolution from SmartAPI Support for this particular error?

6. My conclusion so far

Based on my own testing, I cannot yet rely on this candle-data workflow for validating my trading bot. I would like to understand whether this is an application-side configuration issue, an account-specific restriction, or an API availability/rate-limiting issue.

I am sharing the actual logs and the support team's stated limits so other developers can compare their experiences and share reproducible solutions.

If you use Angel One SmartAPI for algo development, please share whether you have encountered the same issue and how you resolved it.

This post describes my own experience and the support response I received. It is not a claim that every SmartAPI endpoint or every user's experience is unreliable.