<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Access_token on WebNotes</title><link>https://v2.webnotes.in/tags/access_token/</link><description>Recent content in Access_token on WebNotes</description><generator>Hugo</generator><language>en-IN</language><lastBuildDate>Sun, 21 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://v2.webnotes.in/tags/access_token/index.xml" rel="self" type="application/rss+xml"/><item><title>Kite Connect authentication errors: invalid app code and incorrect api_key or access_token</title><link>https://v2.webnotes.in/kite-connect-auth-errors/</link><pubDate>Sun, 21 Jun 2026 00:00:00 +0000</pubDate><guid>https://v2.webnotes.in/kite-connect-auth-errors/</guid><description>&lt;p&gt;&lt;strong&gt;Kite Connect authentication errors&lt;/strong&gt; fall into two layers that are often confused: the human Kite login, where &amp;ldquo;Invalid app code&amp;rdquo; means the second-factor code failed, and the &lt;a href="https://v2.webnotes.in/kite-connect-api/"&gt;Kite Connect API&lt;/a&gt;
, where &amp;ldquo;Incorrect api_key or access_token&amp;rdquo; means a programmatic session is invalid or expired. The first is almost always a device-clock problem on the time-based login code; the second is almost always the daily 6 a.m. expiry of a Kite Connect access token, returned to your program as an HTTP 403 with a TokenException. They look similar because both involve a token and both block access, but they sit at different layers and have different fixes.&lt;/p&gt;</description></item><item><title>How to generate the request_token and access_token on Kite Connect</title><link>https://v2.webnotes.in/how-to-generate-kite-connect-tokens/</link><pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate><guid>https://v2.webnotes.in/how-to-generate-kite-connect-tokens/</guid><description>&lt;p&gt;Every &lt;a href="https://v2.webnotes.in/kite-connect-api/"&gt;Kite Connect API&lt;/a&gt;
 session requires a fresh &lt;code&gt;access_token&lt;/code&gt; that is valid for the current trading day. Generating an &lt;code&gt;access_token&lt;/code&gt; involves a two-step OAuth-style flow: the user logs in through Zerodha&amp;rsquo;s browser-based consent screen to obtain a &lt;code&gt;request_token&lt;/code&gt;, and the server then exchanges that &lt;code&gt;request_token&lt;/code&gt;, along with a cryptographic checksum, for an &lt;code&gt;access_token&lt;/code&gt;. This guide explains both steps using the official &lt;a href="https://v2.webnotes.in/how-to-basic-python-kiteconnect-script/"&gt;kiteconnect Python SDK&lt;/a&gt;
.&lt;/p&gt;
&lt;aside class="callout callout--key" role="note"&gt;
 &lt;strong class="callout__label"&gt;Prerequisites&lt;/strong&gt;
 &lt;div class="callout__body"&gt;&lt;ul&gt;
&lt;li&gt;An active Kite Connect subscription and a valid &lt;code&gt;api_key&lt;/code&gt; and &lt;code&gt;api_secret&lt;/code&gt;. See &lt;a href="https://v2.webnotes.in/how-to-generate-kite-connect-api-key/"&gt;How to generate a Kite Connect API key&lt;/a&gt;
.&lt;/li&gt;
&lt;li&gt;Python 3.8 or later installed.&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;kiteconnect&lt;/code&gt; package installed: &lt;code&gt;pip install kiteconnect&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;The redirect URL registered in your app configured on the developer console.&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;/aside&gt;

&lt;aside class="callout callout--info" role="note"&gt;
 &lt;strong class="callout__label"&gt;Conflict-of-interest disclosure&lt;/strong&gt;
 &lt;div class="callout__body"&gt;WebNotes is an independent knowledge base. This guide is not sponsored by Zerodha or any third party.&lt;/div&gt;
&lt;/aside&gt;

&lt;h2 id="how-the-token-flow-works"&gt;How the token flow works&lt;/h2&gt;
&lt;p&gt;Kite Connect&amp;rsquo;s authentication is modelled on OAuth 2.0 with a custom checksum step. The flow has three actors: your application, the user&amp;rsquo;s browser, and Zerodha&amp;rsquo;s API server.&lt;/p&gt;</description></item></channel></rss>