@jay-patel A few checks from having debugged this exact error family recently:

1. Documented caps for getCandleData are 3/sec AND 180/min AND 5000/hr. Calls 6-10s apart sit well under all three — IF that's the only traffic on the key.

2. Caps are enforced server-side per client code, not per script. Usual silent breaches: a second process/notebook/cron on the same key; instant retries after an AB1021 (each retry counts and extends the throttle); or all 12 symbols fired near-simultaneously at the top of each cycle — that's a >3/sec burst even with 6-10s cycles. Log actual send timestamps, not the loop's sleep schedule.

3. If none apply, escalate with client code + exact timestamps — other threads this period report AB1021 below documented limits, and I hit the server cap on a modest backfill myself.

What works in production: client-side sliding-window limiter enforcing all three caps, exponential backoff on any AB1021, chunked backfills. For live 5-min candles on 12 symbols, consider building bars from the websocket instead of polling.

I do broker-API integration work — DM if you're stuck.

@S57010238 Since login AND placeOrder work but you still get AG8004, the key itself is fine — the failure is scoped to specific endpoints. Which call throws it (getCandleData / market data)?

Two verified findings from debugging the same error family after the April migration:

1. generateSession doesn't validate the API key at all, and endpoint groups validate scopes separately — so "logs in fine" (or even "orders work") proves nothing about the data endpoints.
2. The migration replaced the old KEY TYPEs (Trading / Market Feed / Historical) with unified apps, but apps or keys that straddle the migration can still be rejected on some routes. Recreating the app fresh on the new portal fixed it in my case — note you may then hit "Primary static IP is already associated with another app", because deleted legacy apps don't release their registered IPs.

Full write-up with the complete fix path + two extra gotchas (the Python SDK prints your API key into error logs; NSE Saturday DR-drill sessions serve mock candles as real data): https://smartapi.angelone.in/smartapi/forum/topic/5635/complete-fix-ag8004-invalid-api-key-after-successful-login-primary-static-ip-is-already-associated-with-another-app

If you share which endpoint fails and when the app was created, happy to help narrow it down.

Spent a weekend debugging this after the April 2026 portal migration — posting the complete resolution since the pieces are scattered across many threads.

Symptoms: generateSession succeeds, but every data call (getLtpData, getCandleData) returns AG8004 "Invalid API Key". Creating a new app fails with "Primary static IP is already associated with another app" — even for IPs you registered yourself.

Root causes (verified):

1. generateSession does NOT validate the API key — only client credentials. Dead/legacy keys still "log in" fine and only fail on data endpoints. The dashboard is the only source of truth for keys.
2. The portal migration deleted legacy apps but did NOT release their static-IP registrations. Old IPs stay orphaned inside dead apps.
3. One static IP maps to one client (UCC) — and CGNAT addresses (e.g. Jio mobile ranges) may already be claimed by another user entirely.

Fix path:

1. Don't reuse keys from old emails — legacy keys are dead post-migration even though login "works".
2. Create a fresh app on the new portal. If your IP is "already associated", register a static IP you actually control that has never been registered anywhere (e.g. a fresh cloud elastic IP). The mapped IP can be updated once per calendar week later.
3. Static IP is enforced for ORDER placement only (from 01-Apr-2026). Login/candles/LTP don't check origin IP, so data pipelines and paper trading work from anywhere.
4. Write to support to purge legacy apps and release orphaned IPs.
5. Gotcha #1: the Python SDK's error logger prints your X-PrivateKey (API key) into logs on failed requests — scrub logs before sharing them anywhere (and never commit a logs/ folder).
6. Gotcha #2: NSE Saturday DR-drill sessions return MOCK candles at ~10% off real prices through getCandleData as if real. Filter weekend bars deviating >3% from the prior close (genuine Muhurat/Budget sessions survive that rule).

Working reference implementation (rate-limited wrapper, fetchers with the mock-session guard, honest walk-forward research pipeline): https://github.com/saif859/smartapi-algo

Happy to answer questions. I do broker-API integration work professionally — DM if you're stuck beyond what a forum post can fix.

I have created my account directly with Angel Broking. Not sure why this is happening.

My Client Code: Z673309

Getting the following error for login API.