Is Kite Connect Really Free? What a 2026 Setup Actually Costs

Ask three Kite Connect users what the API costs and you will hear three numbers: ₹2,000 a month, ₹500 a month, and free. All three were right at some point, and the third is only half right today. In October 2026 Zerodha also started waiving the fee for active traders, which is why "free" keeps appearing in posts that skip the conditions.

This is Part 1 of a five-part series on building AI agents on Kite Connect, Zerodha's trading API. Before any agent code, four facts need to be straight: what each plan includes, how the October waiver works, how the daily login behaves, and why placing orders now requires a static IP. Everything below was checked against Zerodha's support pages, developer docs, and forum as of 26 October 2026.

A note on scope: this series is about engineering. It does not recommend trades or strategies, and automated trading can lose real money.

What "free" covers in October 2026

Kite Connect has two plans. The Personal plan is free and carries no market data, live or historical. The paid Connect plan adds both. Everything else is in both plans: order, GTT (Good Till Triggered) and alert management, margin computation, and portfolio data. These descriptions come from Zerodha's Kite Connect FAQ.

The ₹2,000 figure in older write-ups is the base fee from before May 2025, when Zerodha announced a cut to ₹500 a month. Before that, historical data was a separate ₹2,000 add-on, which Zerodha dropped on 8 February 2025. The Personal plan launched the next month. For individuals, Zerodha's current pages list only the two plans above.

Three more rules from the same FAQ matter for agent builders:

• Historical data needs Connect. You cannot subscribe to the historical API on its own.

• Kite data cannot be redistributed. Showing it on other platforms violates exchange data-vending rules, so an agent that republishes prices is out of bounds.

• Startups building mass-retail products can apply for free access by writing to Zerodha.

The first practical consequence shows up fast. Market-data calls on a Personal key fail with an "Insufficient permission" error, and users reported exactly that on the LTP and quote calls when the plan launched. A WebSocket attempt can fail with a 403. Neither means your code is broken, and the error decoder near the end lists both.

How the October fee waiver works

On 7 October 2026 Zerodha announced on its developer forum that it is waiving the Connect subscription fee for active traders. The rules, assembled from that announcement and the staff replies beneath it:

• After each calendar month ends, Zerodha checks your brokerage. ₹2,000 or more earns 500 developer credits, worth ₹500. The credits renew your Connect app for the following month.

• Below the threshold, normal charges apply. No application is needed, and credits appear on the billing page of your developer account.

• You need an active Connect app when the credits are issued. A user with no active app was told this was why no credit arrived.

• Eligibility is assessed per client ID, and credits land in the developer account the app is mapped to. Several apps on one client ID share a single credit.

• Zerodha says the waiver does not change API quality or performance.

Four consequences follow. The waiver applies only to the paid Connect plan, because Personal was already free. It depends on brokerage, so a client ID that never trades generates none and will not qualify. Credits arrive after the month closes, so if you need market data now, expect to pay for the first month yourself.

The fourth is about trust in the details. Several forum users reported confusion about timing and eligibility in the same thread. Check your billing page instead of assuming a credit will appear, especially near the threshold, where the wording is not consistent across Zerodha's own replies (see the table near the end).

Which plan an agent needs, and what it costs

Start from what the agent will do, not from the price.

flowchart TD
    A[What does the agent need?] --> B{Live prices, WebSocket ticks or historical candles?}
    B -- Yes --> C[Connect plan: ₹500 per month per API key]
    B -- No --> D[Personal plan: free]
    C --> H{Will it place or change orders?}
    D --> H
    H -- Yes --> I[Whitelist a static IP first]
    H -- No --> J[Run from any IP]

A first agent that reads holdings, margins, and positions and explains them needs nothing beyond Personal. That is a useful place to start, because you can build and debug the whole login, tooling, and prompt layer at zero cost. Move to Connect when the agent has to reason about prices, and only then. Here is what each setup costs:

The middle row holds only while you stay above the threshold. One quiet month and the fee returns.

The login flow in five steps

Kite Connect uses an OAuth-style login flow, documented in the login flow reference. It is the same for a script, a web app, or an agent's tool.

sequenceDiagram
    actor You
    participant Login as Kite login page
    participant App as Your login script
    participant API as api.kite.trade
    You->>Login: Open login URL with your api_key
    Login->>You: Password and 2FA prompt
    You->>Login: Complete 2FA
    Login-->>App: Redirect to your URL with request_token
    App->>API: POST /session/token with api_key, request_token, checksum
    API-->>App: access_token
    App->>API: Every later call carries the access_token

1. Send the user to https://kite.zerodha.com/connect/login?v=3&api_key=YOUR_KEY.

2. After login and 2FA, Kite redirects to the redirect URL you registered, with a request_token. It is one-time and lives only a few minutes.

3. POST to /session/token with the header X-Kite-Version: 3 and the form fields api_key, request_token, and checksum.

4. The checksum is the SHA-256 hash of api_key + request_token + api_secret, concatenated in that order.

5. The response contains the access_token. Send it on every call as Authorization: token api_key:access_token. The scheme is token, not Bearer.

The official Python client handles the checksum for you. The helper below, written against pykiteconnect 5.2.2 (pip install kiteconnect, or uv add kiteconnect), splits the flow into two functions on purpose:

import json
import os
import stat
from datetime import datetime
from pathlib import Path
from zoneinfo import ZoneInfo

from kiteconnect import KiteConnect
from kiteconnect.exceptions import TokenException

SESSION_FILE = Path(".kite_session.json")
IST = ZoneInfo("Asia/Kolkata")


def today() -> str:
    return datetime.now(IST).date().isoformat()


def new_client() -> KiteConnect:
    return KiteConnect(api_key=os.environ["KITE_API_KEY"])


def login() -> KiteConnect:
    """Run by a human, once per day, in a terminal the agent cannot read."""
    kite = new_client()
    print("Log in here, finish 2FA, then copy request_token from the redirect URL:")
    print(kite.login_url())
    request_token = input("request_token: ").strip()
    data = kite.generate_session(
        request_token, api_secret=os.environ["KITE_API_SECRET"]
    )
    SESSION_FILE.write_text(
        json.dumps({"issued_on": today(), "access_token": data["access_token"]})
    )
    SESSION_FILE.chmod(stat.S_IRUSR | stat.S_IWUSR)
    kite.set_access_token(data["access_token"])
    return kite


def load() -> KiteConnect:
    """Called by scripts the agent writes. It never prompts and never needs the secret."""
    if not SESSION_FILE.exists():
        raise RuntimeError("No session file. Run the login step first.")
    saved = json.loads(SESSION_FILE.read_text())
    if saved["issued_on"] != today():
        raise RuntimeError("Session is from an earlier day. Log in again.")
    kite = new_client()
    kite.set_access_token(saved["access_token"])
    try:
        kite.profile()
    except TokenException as exc:
        raise RuntimeError("Kite rejected the token. Log in again.") from exc
    return kite

The split is the point. Only login() needs the API secret, and a human runs it. Every script the agent writes calls load(), which needs the public KITE_API_KEY and the saved token, so the secret never enters the agent's environment. The token file is still a live credential, so keep it out of version control and out of prompts. This limits exposure but does not make a token safe from a tool that can read your filesystem.

A first script for the agent to run needs four lines:

from kite_session import load

kite = load()
print("Available cash:", kite.margins(segment="equity")["available"]["cash"])
print("Holdings:", len(kite.holdings()))

Zerodha also publishes an agent setup page for coding agents. It gives you a prompt URL to hand to your agent, recommends installing pykiteconnect with uv, and notes that every docs page is available as Markdown by appending .md.

Use it, with two gaps in mind. Its order example does not mention that orders from an unregistered IP are rejected, and the page says nothing about market protection. The static IP rule is covered below, and market protection in Part 4.

Register http://127.0.0.1:8000 as the redirect URL while testing. Zerodha's sign-up guide says localhost is fine for that. Nothing needs to be listening there: the browser will show a connection error, but the request_token is still in the address bar.

The daily login is a design constraint

The access token is valid for the trading day. Zerodha's developer docs say it expires at 6 AM the next day, a regulatory requirement, and sooner if you invalidate it through the API or do a master logout from the Kite web terminal. The FAQ describes the same limit as expiring before market open. Individual apps get no refresh token, since the docs reserve that field for certain approved platforms. Once the token lapses, a human completes the browser login again.

The rule is exchange-driven. A September 2026 reply on Zerodha's forum says users must log in manually at least once a day, that the token cannot be refreshed or generated automatically for individual users, and that Zerodha neither recommends nor supports automating the login. In the waiver thread, one commenter asked for TOTP-based token generation. At the time of writing there was no reply to that request.

For agent design, this settles three questions before you write any prompt:

• The agent never logs in. On a TokenException it stops and tells you. Automating the login would work against the rule above.

• One process owns the session. The FAQ states that a token becomes invalid if a new session is generated with the same API key. Two agents, or an agent plus your own script, can log each other out.

• Morning jobs start after your login, not at a fixed time. A 2018 forum thread reported tokens dying anywhere between 6 and 7:30 AM, so a clock check is unreliable. Let load() fail loudly and treat that as the signal.

Static IP: the step older tutorials skip

Since 1 April 2026, any order placed through the API must come from a static IP registered in your developer console, according to Zerodha's static IP guide. The rule traces to SEBI's 4 February 2025 circular on retail algo trading. Its start date slipped from 1 August 2025 to 1 October 2025, and a 30 September 2025 circular set 1 April 2026 as the date the framework applies to all brokers. NSE issued its implementation standards on 5 May 2025 as circular NSE/INVG/67858.

Reads are unaffected. The WebSocket stream, order book, positions, and similar endpoints still work from any IP, so a read-only agent needs no static IP at all. The details that trip people up:

Two misreadings are common. A strategy under 10 orders per second still needs the static IP. The exchange-registration requirement applies only above that rate. And the IPv6 mismatch is easy to hit: if your machine reaches Zerodha over IPv6 while you whitelisted an IPv4 address, orders are rejected even though everything looks configured.

Where do you get a static IP? Zerodha's FAQ names three sources: an ISP, a cloud provider such as AWS or GCP, or a VPN or VPC service. A laptop on home broadband usually has an address that changes, and so do hosting platforms that rotate their outbound addresses. Neither works for placing orders.

The practical rule for the series: build read-only first, and add the static IP only when you add order tools. That keeps your riskiest capability behind a deliberate setup step.

An error decoder for agents

An agent reads error strings and tries to fix them, so it helps to know which errors point at setup instead of code. Each row below comes from Zerodha's FAQ.

The right response is almost never "retry harder". Most of these need a human decision.

No sandbox, and no phone support

Zerodha states that it does not offer a sandbox environment for Kite Connect. It also provides no API support by phone or ticket, and sends coding questions to the community forum. Both facts shape how you test an agent.

Anything that touches orders is tested against a live account. Read endpoints are the safe rehearsal space. Part 4 covers how to build guardrails so a test with real money behaves like one.

Where the sources disagree

Two details differ between sources. Neither is fatal, but each can cost an afternoon.

For the first, the dedicated guide and the forum's April deadline notice agree on 2026, so treat the FAQ's year as a typo. For the second, stay clearly above the brokerage threshold if you plan around the waiver.

Setup checklist

What comes next

Part 2 builds a first real script on the free Personal plan: reading holdings and margins, then wrapping them as tools an agent can call. Part 3 looks at Kite MCP, Zerodha's own server for connecting AI assistants, and what it exposes. Part 4 builds the order guardrails. Part 5 moves to streaming data on the paid plan.

If you only do one thing after this article, run the login helper once and confirm the four-line script prints your cash balance. Everything later in the series builds on that session working.