← AITrading.in · Blog

Kite Connect API for Algo Trading: What to Check First

Zerodha's Kite Connect is a broker API that lets your own code place orders and read market data. It is well documented, so it is worth reading the documentation before you build anything. Some problems that surprise first-time algo builders, such as a bot that stops when its login expires or an order that was accepted but never filled, are described in plain words on the official pages.

This article is a checklist of what to confirm before you write your strategy around the API. The points below come from Zerodha's published documentation, read on 19 October 2026. Plans and limits change, so confirm each point on the current pages. This is general information, not investment advice.

1. Which plan do you need?

Zerodha's API page lists two plans. The Personal plan is free and covers order, GTT and alerts management, margin computation and portfolio management. The Connect plan is described as the "full suite of APIs with realtime WebSocket streaming and historical candle data" and is listed at ₹500 per month as of 19 October 2026. Check the page before you rely on that figure.

The practical question is what your strategy needs:

Decide this first, because it changes your architecture. A strategy that polls prices over HTTP behaves very differently from one that listens to a stream.

2. The login is not a one-time setup

Kite Connect uses a login flow with several steps. The user logs in, is redirected to your registered redirect URL with a request_token, and your application exchanges that token for an access_token. Two details need attention:

The token expires every day

The most important point for automation: unless it is invalidated through the API or by a master logout from the Kite web terminal, the access_token expires at 6 AM the next day. The documentation calls this a regulatory requirement. For an unattended bot, a daily re-login is part of the design, not an exception.

Plan for it. Ask "what happens at 6 AM every day?" and "what happens if the login fails tomorrow morning?" An alert when a login does not complete is a sensible safeguard.

3. Know the rate limits before you hit them

The documentation sets per-second limits by endpoint type:

Endpoint type Limit
Quote 1 request per second
Historical candle 3 requests per second
Order placement 10 requests per second
All other endpoints 10 requests per second

The orders limits are 400 orders per minute, 10 orders per second, no more than 5,000 orders per day for a single user or API key, and a maximum of 25 modifications per order. An HTTP 429 response means you are being rate-limited.

Two consequences for design:

  1. A backtest that downloads history must respect the 3-per-second candle limit. Pulling years of minute data for many instruments takes time, so use a queue with a throttle rather than a tight loop.
  2. A strategy that modifies an order on every tick, such as a trailing stop, can reach the 25-modification cap. Decide how often an order really needs to change.

4. Streaming has its own limits

The WebSocket documentation allows up to 3,000 instruments on one connection, and up to three connections per API key. For most retail strategies that is plenty. Count your instruments before you design the subscription.

5. An accepted order is not a filled order

The orders documentation says that placing an order "implies registering it with the OMS via the API. This does not guarantee the order's receipt at the exchange." A successful API response means the broker's system accepted the request. It does not mean you hold a position.

Track each order through its statuses rather than assuming a fill. The documented statuses include OPEN, COMPLETE, CANCELLED and REJECTED, along with interim states such as OPEN PENDING. Some habits follow from this:

6. Contracts expire

If you trade futures or options, contracts expire on a schedule. A script that hard-codes last month's contract will fail, so reload the instrument list regularly rather than relying on a fixed list. For why this matters when you test a strategy, see our guide on paper trading versus live trading.

7. Rules change, so check the current notices

Broker and exchange rules for API trading can change. Check your broker's current notices before you go live, and confirm your own setup with your broker. Our guide, Is Algo Trading Legal in India?, is a starting point, not a substitute for the rules themselves.

8. A design checklist

  1. Pick the plan that matches your data needs, and check the price on the current page.
  2. Store the API key and secret outside your code, and never log the access token.
  3. Automate the daily login and alert yourself when it fails.
  4. Throttle every request type to its documented limit, and handle HTTP 429.
  5. Subscribe to streaming data within the per-connection and per-key limits.
  6. Track every order to a final status. Never treat an accepted order as a fill.
  7. Reload the instrument list regularly so expiring contracts are correct.
  8. Check your broker's and the exchange's current rules before going live.
  9. Add your own safety limits: maximum order size, a daily loss cap and a kill switch.
  10. Paper trade first, then start live trading with a small size.

If you would rather not build the plumbing yourself

The login refresh, error recovery and rate limiting are unglamorous work, and they are where most hobby bots break. The ai-trading.in home page describes automated trading systems for Zerodha Kite Connect and Dhan, with token refresh and error recovery, daily loss limits, a paper trading mode and Telegram alerts.

Whether you build or buy, the checklist is the same: read what the broker publishes, design for the daily reset, and never assume that an accepted order is a filled one.

Sources

All pages were read on 19 October 2026.

This article is general information, not legal or financial advice.