I run an intraday algo on Kite Connect (Python). My daily flow:
Complete the login → request_token → access_token exchange once in the morning (single API key, single user). Use that access_token for a KiteTicker WebSocket (live ticks) plus periodic REST calls (ltp, historical_data). Today I hit an unexpected mid-session token invalidation:
Timeline (IST):
08:55 — generated a fresh access_token via the login flow. Everything worked — WebSocket streamed ticks, REST calls succeeded. ~13:39 — REST calls suddenly began failing with: TokenException (HTTP 403) — "Invalid api_key or access_token." (This is the same time I opened my Kite Mobile App for the first time today to check market) 14:25 — I re-ran the login flow to mint a new token, which resolved it.
Key point: my app generated no new access_token between 08:55 and 13:39 — I confirmed from my server logs that there were only two token-exchange events all day (08:55, and the 14:25 recovery). So the 08:55 token was invalidated without my app re-authenticating, even though I'd expect it to stay valid until ~06:00 the next day.
Questions:
1. Does an interactive login to Kite web/mobile with the same user invalidate an already-active Kite Connect API access_token? 2. Is there a single-active-session limit per user spanning the API and the consumer app? If so, which session wins? Notably, my KiteTicker WebSocket kept streaming ticks fine even after REST started returning 403. Once connected, is the ticker session independent of the REST access_token? 3. What's the recommended pattern for running an intraday API session while still occasionally using the Kite app on the same account - or is a separate Zerodha account for the API the only clean solution?
1. Does an interactive login to Kite web/mobile with the same user invalidate an already-active Kite Connect API access_token?
Logging in to Kite Web or the Kite app does not invalidate an active Kite Connect API access_token. Both can be used independently.
2. Is there a single-active-session limit per user spanning the API and the consumer app? If so, which session wins? Notably, my KiteTicker WebSocket kept streaming ticks fine even after REST started returning 403. Once connected, is the ticker session independent of the REST access_token?
You can use Kite Connect and the Kite app simultaneously. The KiteTicker WebSocket authenticates when the connection is established and maintains its own connection thereafter.
3. What's the recommended pattern for running an intraday API session while still occasionally using the Kite app on the same account - or is a separate Zerodha account for the API the only clean solution?
You should be able to use the same Zerodha account for both Kite Connect and the Kite app; a separate account is not required for this. If the issue persists, please get back to us with the relevant details, so we can investigate further.
Also, please check whether your application has any logic that explicitly invalidates access_token, as this could also result in the observed behaviour.
Thank you @Nivas . This helps. I found the cause on my side: my /api/zerodha/status health-check endpoint caught all exceptions and cleared the stored access_token, so a 7-second ReadTimeout on profile() deleted a valid token mid-session. Subsequent calls then failed with InputException (400) Invalid api_key or access_token, which I misread as Zerodha invalidating the session. I Fixedthis, only a TokenException clears stored credentials now; timeouts and 5xx are treated as transient.
One follow-up if you're able to explain or if you need logs , tell me what in the logs you expect: on 2026-08-20 at 13:39 IST I saw a genuine TokenException (403) roughly 4h45m after minting the token, with no second generate_session call from my side in between. Is there anything other than a fresh login that can invalidate a session mid-day?
The token should get invalidated only if the user invalidates it using the logout endpoint. If you encounter this issue in the future, please drop an email to [email protected] with the log details and account-specific details to investigate further.
Also, please check whether your application has any logic that explicitly invalidates access_token, as this could also result in the observed behaviour.
I found the cause on my side: my /api/zerodha/status health-check endpoint caught all exceptions and cleared the stored access_token, so a 7-second ReadTimeout on profile() deleted a valid token mid-session. Subsequent calls then failed with InputException (400) Invalid api_key or access_token, which I misread as Zerodha invalidating the session. I Fixedthis, only a TokenException clears stored credentials now; timeouts and 5xx are treated as transient.
One follow-up if you're able to explain or if you need logs , tell me what in the logs you expect: on 2026-08-20 at 13:39 IST I saw a genuine TokenException (403) roughly 4h45m after minting the token, with no second generate_session call from my side in between. Is there anything other than a fresh login that can invalidate a session mid-day?