1. Home
  2. Categories
  3. Python SDK
  4. Complete fix: AG8004 "Invalid API Key" after successful login + "Primary static IP is already associated with another app"

Complete fix: AG8004 "Invalid API Key" after successful login + "Primary static IP is already associated with another app"

Python SDK
Log in to reply
  • S

    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.

    0