1. Home
  2. Groups
  3. SmartAPI Group

Group Details Private

SmartAPI Group

Member List

A admin
R roundishmouse
K K299360
S sreedhar
I ir9ir9
Y Y15996
H harishgrt
V Vividhity
C cjaiswal
A avim
T Trishul
S Saravanan_K
J J16859
H hemil.quarec
A abhinavgarg26
H H33228
A algolyte
S Sivavalli1457
G gauravchovatiya
C Chandraparsad01
  • A

    Setup:

    SmartAPI REST
    Segment: NFO
    Product: NRML (CARRYFORWARD)
    Variety: NORMAL
    Order type: LIMIT

    On 11-Sep-2026 at 09:20:09, the following order was rejected:
    RMS:Rule: Position limit including CNC exceeds, Current:60, limit set:1

    Rejected order:
    SELL BANKNIFTY29SEP2654700CE
    Quantity: 60
    Product: NRML

    However, three other position-opening orders for the same client code were completed within the same second:

    Time Order Qty Status
    09:20:08.583 BUY BANKNIFTY29SEP2656800CE 90 Complete
    09:20:08.651 BUY BANKNIFTY29SEP2654600PE 90 Complete
    09:20:08.924 SELL BANKNIFTY29SEP2656700PE 60 Complete
    09:20:09.044 SELL BANKNIFTY29SEP2654700CE 60 Rejected

    If the position limit on this account were genuinely 1, all four orders should have been rejected, not just the fourth order.

    Also, at around 11:19 on the same day, the following order was accepted normally:

    SELL BANKNIFTY29SEP2655200CE – Quantity 60 – NRML

    This account regularly trades quantities of 60 and 90 every trading day.

    Questions
    Is a client-level position limit configured on this account? If yes, what is its value?
    If the limit is 1, why did the three previous orders with quantities 90, 90, and 60 complete successfully within the same second?
    Can rapid API activity on the same client code cause RMS to evaluate a new order against an incomplete or delayed position snapshot?

    Please clarify what exactly Current:60, limit set:1 represents in this RMS rejection message.

    • read more
  • Q

    @admin when is the near future arriving ? when will we get support for ipv6?

    • read more
  • P

    Re: SmartAPI getCandleData returns 403 rate-limit error despite being under documented limits

    Same issue for me. Even for a single call, just after login, this API returns "Access denied because of exceeding access rate"

    Can someone or Admin respond to this issue?

    I was not facing this issue few months back and everything worked fine. Later, I was getting this error occasionally (like few failures per day). Now it is failing for a single call itself.

    • read more
  • P

    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.

    • read more