This is a very old bug which we had reported this prior as well. Your api limit check component does not seem to functioning properly.

We are observing intermittent HTTP 403 responses with the error message "Access denied because of exceeding access rate" on the Order Book endpoint, even though our actual request rate is well below the documented limit. We suspect this may be a bug in the rate-limit check on your side and would appreciate your investigation.

Account details

• Client Code: AAAJ371742
• API Key: gq**8Ur4 (happy to share the full key over a secure channel if needed)
• Source IP: single registered static IP

Endpoint

• GET
  https://apiconnect.angelone.in/rest/secure/angelbroking/order/v1/getOrderBook
• Published rate limit (per https://smartapi.angelbroking.com/docs/RateLimit): 1 request / second / client

Observed behaviour Our service polls the order book every 3–4 seconds for this single account — i.e., ~0.25–0.33 req/s, which is roughly 3–4× below the published ceiling. Despite this, we routinely see 403 "exceeding access rate" responses. Representative timestamps from today's (2026-04-13) run, IST:

12:21:06.xxx  403 "Access denied because of exceeding access rate"
12:30:38.xxx  403 "Access denied because of exceeding access rate"
12:30:59.xxx  403 "Access denied because of exceeding access rate"
12:31:11.xxx  403 "Access denied because of exceeding access rate"
12:31:14.xxx  403 "Access denied because of exceeding access rate"
12:31:44.xxx  403 "Access denied because of exceeding access rate"

Between these errors, the client issued only one getOrderBook call every 3–4 seconds, with no bursts and no other endpoints being called at high frequency.

Request headers on the failing calls (standard per your docs)

Authorization: Bearer <jwt>
X-PrivateKey: <apiKey>
X-UserType: USER
X-SourceID: WEB
X-ClientLocalIP: <local ip>
X-ClientPublicIP: <public ip>
X-MACAddress: <mac>
Accept: application/json
Content-Type: application/json

What we'd like confirmed

• Is the 1 req/s limit on getOrderBook measured per-client-code, per-API-key, or per-source-IP? The docs say "per client" — we want to confirm which identifier this is bucketed against.
• Is the rate-limiter's sliding window implemented correctly? The error pattern (several 403s within the same minute, despite steady ~0.3 req/s traffic) suggests the counter may be leaking counts from unrelated windows or accounts.
• Can you inspect server-side rate-limit telemetry for AAAJ371742 during 2026-04-13 12:20–12:32 IST and confirm whether the observed denials correspond to the actual measured rate for this client, or whether they are false positives?