Team,

I am posting it here as multiple emails to smartapi@angelbroking.com has resulted in complete misunderstanding.

I hope someone with enough technical skills reads this issue.

All leading brokers support IPv6 except Angel One.

When I asked the support, the response I got was that you do support it.

While testing it turned out that you only support whitelisting an IPv6 address. And completely miss the fact that your network has to support IPv6 natively for the connection to happen & then your servers must recognize the source IPv6 address in order to match with whitelisted IPv6.

Getting a IPv6 whitelisted is of no use we cannot make an IPv6 connection.

This is so basic stuff, that team failing to understand such basics raises questions about the skills of the staff involved. Hence, I hope someone with enough knowledge reads and responds to this instead of giving embarrassing responses.

Technical Details:

We are trying to connect to the Angel One API (apiconnect.angelone.in) over IPv6 for account (AAAJ165582) with IPs already whitelisted on your website, but the connection fails with the following error:

Network/Transport Error: null: apiconnect.angelone.in/103.82.178.77:443; nested exception is io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: null: apiconnect.angelone.in/103.82.178.77:443

Upon investigation, we found that apiconnect.angelone.in only has an A record (IPv4: 103.82.178.77) and no AAAA record (IPv6). This means clients on IPv6-only networks cannot reach your API.

> nslookup -type=A apiconnect.angelone.in 8.8.8.8
Name: apiconnect.angelone.in
Address: 103.82.178.77

> nslookup -type=AAAA apiconnect.angelone.in 8.8.8.8
Name: apiconnect.angelone.in
(No IPv6 address returned)

Could you please confirm whether IPv6 support is planned for your API endpoints? We would appreciate it if AAAA DNS records could be added to enable IPv6 connectivity.

@admin I had a hard time explaining this to your email support team & they never understood. So I am sharing my details below:

A simple nslookup command can tell you that your API lacks IPv6 support.

ZERODHA

nslookup -type=AAAA api.kite.trade 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    api.kite.trade
Addresses:  2606:4700::6810:2232
          2606:4700::6810:2132

UPSTOX

nslookup -type=AAAA api.upstox.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    api.upstox.com.cdn.cloudflare.net
Addresses:  2606:4700:4401::6812:284d
          2a06:98c1:3109::ac40:93b3
Aliases:  api.upstox.com

ANGEL ONE

nslookup -type=AAAA apiconnect.angelone.in 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Name:    apiconnect.angelone.in

(No IPv6 address returned for ANGEL ONE)

@admin Thanks for responding. Any expected timeline?

We are literally losing Angel customers everyday due to this limitation.

This is a loss for Angel as well.

@algo_trading_50 Please have a look at below response from smartapi team received just a few days ago.

@algo_trading_50 We were testing with this account for the specific use-case and no other api endpoint was being invoked during the test.

Team,

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?

Team,

I am posting it here as multiple emails to smartapi@angelbroking.com has resulted in complete misunderstanding.

I hope someone with enough technical skills reads this issue.

All leading brokers support IPv6 except Angel One.

When I asked the support, the response I got was that you do support it.

While testing it turned out that you only support whitelisting an IPv6 address. And completely miss the fact that your network has to support IPv6 natively for the connection to happen & then your servers must recognize the source IPv6 address in order to match with whitelisted IPv6.

Getting a IPv6 whitelisted is of no use we cannot make an IPv6 connection.

This is so basic stuff, that team failing to understand such basics raises questions about the skills of the staff involved. Hence, I hope someone with enough knowledge reads and responds to this instead of giving embarrassing responses.

Technical Details:

We are trying to connect to the Angel One API (apiconnect.angelone.in) over IPv6 for account (AAAJ165582) with IPs already whitelisted on your website, but the connection fails with the following error:

Network/Transport Error: null: apiconnect.angelone.in/103.82.178.77:443; nested exception is io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: null: apiconnect.angelone.in/103.82.178.77:443

Upon investigation, we found that apiconnect.angelone.in only has an A record (IPv4: 103.82.178.77) and no AAAA record (IPv6). This means clients on IPv6-only networks cannot reach your API.

> nslookup -type=A apiconnect.angelone.in 8.8.8.8
Name: apiconnect.angelone.in
Address: 103.82.178.77

> nslookup -type=AAAA apiconnect.angelone.in 8.8.8.8
Name: apiconnect.angelone.in
(No IPv6 address returned)

Could you please confirm whether IPv6 support is planned for your API endpoints? We would appreciate it if AAAA DNS records could be added to enable IPv6 connectivity.