Posts made by pari

@keshav-0 Multiple people are facing these issues and the admins here on this forum either do not exist or are completely unequipped to deal with anything other than giving vague useless replies. I have sent a detailed mail to support@angelone.in and escalation@angelone.in. If there is no satisfactory resolution, I'm planning to escalate directly to the CEO, Mr Ambarish Kenghe (ceoescalation@angelone.in) and post it all over social media like X/Twitter, tagging AngelOne's X handle.

I suggest you and everybody facing issues use these channels as well to voice their issues since the administrators of this form have proved themselves completely incompetent.

Multiple people are facing these issues and the admins here on this forum either do not exist or are completely unequipped to deal with anything other than giving vague useless replies. I have sent a detailed mail to support@angelone.in and escalation@angelone.in. If there is no satisfactory resolution, I'm planning to escalate directly to the CEO, Mr Ambarish Kenghe (ceoescalation@angelone.in) and post it all over social media like X/Twitter, tagging AngelOne's X handle.

I suggest everybody facing issues use these channels as well to voice their issues since the administrators of this form have proved themselves completely incompetent.

Facing the same issue. I've already posted this on a separate thread and others have confirmed that they are facing this issue as well. As usual the admins from Angel One are completely ignoring all the posts. Have some shame @admin. You guys reply selectively when it suits you and the replies are just "brush offs" on genuine issues being raised. I'm astounded that a company runs like this. I think it's time to involve some direct contacts on the escalation chain listed on their website and also start tagging their X/Twitter handle.

Separate issue from the getCandleData/getOrderBook rate-limit thread (topic 5639) — this is the static scrip master file itself, unauthenticated, no API key involved.

Endpoint: GET https://margincalculator.angelbroking.com/OpenAPI_File/files/OpenAPIScripMaster.json (~37MB, Content-Length: 36952921 confirmed via HEAD)

Production symptom (Python, urllib.request.urlopen().read()): three consecutive attempts between 09:15 and 09:44 IST today all failed with http.client.IncompleteRead — the server closed the connection before delivering the promised Content-Length, with successively less data delivered each time:

• 09:15:04 — 648,242 bytes read, 36,304,679 more expected
• 09:36:31 — 572,061 bytes read, 36,380,860 more expected
• 09:43:37 — 393,216 bytes read, 36,559,705 more expected

Independently reproduced from a completely different network (not the machine the above ran on) using plain curl, tested over both IPv6 and IPv4-forced, same URL:

• 60s attempt: 4.25MB delivered, ~71KB/s
• 60s attempt (IPv4 forced): 2.93MB delivered, ~49KB/s
• 180s attempt: connection closed by the server at 3.5MB (~48KB/s) — well short of 37MB even at that slow rate
• Retested ~90 minutes later: 336KB in 60s, ~5.5KB/s — getting worse, not better
• Baseline sanity check on the same network in the same window: an unrelated 10MB file from a different host downloaded at 3.1MB/s, ruling out a local bandwidth problem on our end

So this isn't one flaky client or one flaky network — two different tools (Python urllib, curl), two different networks, and both IP protocols all show the same severe throttling against this one host, persisting for over an hour and trending worse.

This is a hard blocker — the scrip master is a prerequisite before any strategy can even start routing, so trading has been unable to start today because of this alone.

Anyone else seeing this on margincalculator.angelbroking.com today? Given the pattern of the last several days on the rate-limit thread above, I'd appreciate someone actually looking at server-side telemetry/CDN health for this endpoint rather than the usual silence.

@admin Come on Angel One. Show some professionalism. At least respond. Completely ignoring genuine issues is very unprofessional and reflects very poorly on the company culture and ethics.

@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?

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.

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.

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.

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.

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.

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.

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.

@admin Ok. Thanks for the clarification. Also please update your documentation for rate limits. The documentation still says 20 orders per second.

@admin The procedure to register the static IP address has changed from what you had posted on this forum earlier. Before you implemented "new login", I had already created an API key with my static IP address on the old login link. Now I'm not able to use that IP address since it's already in use. Even when I disable the old API key, I'm not able to use the IP address. Why have you created so much confusion? Can I continue using the old API key since it's already linked to the static IP? Please clarify.

@diwakarpant16 No. Still not working.

This is a serious issue as the algo makes decision based on ltp data. This could lead to huge losses if not addressed immediately. The moderator/admin is completely absent and no acknowledgement at all.

@moderator Why is there no response from your end? No acknowledgement. Nothing.

The ltpData method is returning yesterday's ltp data at close.

Please fix this ASAP.

@admin Any updates on this? I've been facing this issue the entire day.