pykiteconnect: the official Python client for the Kite Connect trading APIs

What the Kite Connect API is, and what this library adds

The library is the official Python client for communicating with the Kite Connect API, which the README describes as a set of REST-like APIs that expose many of the capabilities required to build a complete investment and trading platform, so you can execute orders in real time, manage a user portfolio and stream live market data over WebSockets. The client is a thin layer with named constants, which is the main ergonomic difference from calling the HTTP endpoints yourself, since every exchange, variety, transaction type, product and validity is a constant on the client rather than a string literal in your code. The documentation is split in two, with the Python client documentation and the HTTP API documentation maintained separately, which is a reasonable division since the client is a convenience layer and the API is the contract. The package is on PyPI as `kiteconnect`, licensed MIT, and the copyright line names Zerodha Technology with the year 2021.

The session dance, and where the token comes from

Authentication is a three step flow that the README's example walks through. You construct the client with your API key, redirect the user to the URL from `login_url()`, and receive a request token from the registered redirect URL after the login flow. With that request token you call `generate_session()` together with your API secret, and the returned data contains the access token, which you set with `set_access_token()`. The client is then ready for the authenticated endpoints.

import logging
from kiteconnect import KiteConnect

logging.basicConfig(level=logging.DEBUG)

kite = KiteConnect(api_key="your_api_key")

data = kite.generate_session("request_token_here", api_secret="your_secret")
kite.set_access_token(data["access_token"])

For a service that runs unattended this is the part to get right, because the request token comes from an interactive login, so an automated deployment needs a way to obtain and refresh the session, which is a design problem in your application rather than something the client solves. The library gives you the endpoints, not the session lifecycle.

Placing orders, listing them, and the mutual fund variant

The order surface in the README's example shows the shape of a call. `place_order` takes the trading symbol, the exchange, the transaction type, the quantity, the variety, the order type, the product and the validity, with the constants named on the client, and the example uses a market order with an `AMO` variety and a `CNC` product and a day validity. The example then shows the read calls, with `orders()` to fetch all orders and `instruments()` to get the instrument list, which is the call every strategy needs and also the one that returns a large payload. Mutual funds have their own trio, with `place_mf_order()` taking the symbol, the transaction type, an amount rather than a quantity and a tag, `cancel_mf_order()` taking an order id, and `mf_instruments()` for the fund catalogue. The amount based mutual fund order is the detail that matters, because mutual funds trade in amounts, and a client that only modelled quantity would be unusable for that market.

Auto slicing for orders that exceed exchange freeze limits

The most interesting feature in the library is `place_autoslice_order()`, added in v5.2, and it exists because of a real exchange constraint. When an order exceeds the freeze limit for that symbol, the order is automatically split into multiple smaller orders internally, and the response contains the parent `order_id` together with a `children` list where each child is either a placed order with its own `order_id` or an `error` payload. The shape of the call mirrors a normal order, with the variety, the exchange, the trading symbol, the transaction type, the quantity, the product and the order type, and the example uses a futures symbol with a large quantity.

response = kite.place_autoslice_order(
    variety=kite.VARIETY_REGULAR,
    exchange=kite.EXCHANGE_NFO,
    tradingsymbol="NIFTY25APRFUT",
    transaction_type=kite.TRANSACTION_TYPE_BUY,
    quantity=100000,
    product=kite.PRODUCT_MIS,
    order_type=kite.ORDER_TYPE_MARKET,
)

The handling of the children list is where the care is needed, since a slice can be partly placed and partly failed, and the README's example shows exactly that loop, checking for `order_id` in each child and treating anything else as the error payload. A caller that ignores the children and only looks at the parent order id will believe an order succeeded when half of it did not.

WebSocket market data, and the reconnect rule you need to know

The streaming side uses the `KiteTicker` class, constructed with the API key and the access token, and driven by three callbacks. `on_ticks` receives the market data, `on_connect` fires on a successful connection and is where you subscribe to a list of instrument tokens, and `on_close` receives the close code and reason. There is also a mode call, `set_mode(ws.MODE_FULL, [738561])`, which switches a symbol to the fuller quote packet. The detail worth reading twice is the comment on the close handler, that on connection close you stop the main loop and that reconnection will not happen after executing `ws.stop()`. That is a different contract from most socket libraries, where a dropped connection is transparently retried, and a service built on the assumption of automatic reconnection will silently stop receiving ticks. The `examples/` directory includes a threaded ticker example and a plain one, plus a Flask application example and a couple of order examples, which is the fastest way to see the intended threading model.

Version history, breaking changes and the Python 2 decision

The README keeps a running list of breaking changes, and there are two worth knowing about. The v4 changes renamed the ticker fields to match the Kite Connect documentation, and renamed `bsecds` to `bcd` in `ticker.EXCHANGE_MAP`, so both affect code that reads market data. The v5 change dropped support for Python 2.7, and the README gives the reason rather than a preference, pointing at the announcement by `setup-python` that stopped supporting Python 2.x in May 2023. It also tells Python 2 users what to do, that they can keep using the library but should stay on the 4.x.x versions, with the previous releases linked. The current line is 5.2.x, with 5.2.0 in April 2026, 5.2.1 in July 2026 and 5.2.2 in September 2026.. The README header still says v4, which is a leftover from when the document was written and a reminder to check the client documentation for the version you are actually using.

Installation, the C extension problem and the Windows compiler matrix

The installation section is longer than it should be, and the reason is that some dependencies use C extensions and therefore have to be compiled before the package installs. The README recommends `pip install --upgrade kiteconnect`, and if you hit installation problems it recommends updating pip and setuptools with `pip install -U pip setuptools`. On Linux and the BSDs you need a C compiler such as GCC, and the README gives the headers to install per distribution, with `apt-get install libffi-dev python-dev python3-dev` on Debian and Ubuntu, `yum install libffi-devel python3-devel python-devel` on CentOS, RHEL and Fedora, and `xcode-select --install` on macOS. Windows is the hard case, because each Python version needs a specific compiler version, with the README mapping Python 2.6 through 3.2 to Visual C++ 9.0, 3.3 and 3.4 to 10.0, and 3.5 and 3.6 to 14.0. The dependency set explains why, since the install requirements include pyOpenSSL, service_identity, requests, six, python-dateutil and a pinned `autobahn[twisted]==19.11.2`.

Editorial conclusion

Adopt pykiteconnect if you are building on the Kite Connect API in Python and you want the official client rather than hand written requests, particularly if you want the auto slice behaviour for oversized orders and the WebSocket ticker helpers. Do not adopt it without reading the version history, because v4 renamed ticker fields and the exchange map key, and v5 dropped Python 2.7, so an upgrade touches your code. Before you install, plan for the build requirements, since some dependencies use C extensions and the README asks for the development headers of your platform, and on Windows for the compiler that matches your exact Python version. The licence is MIT, the current release is 5.2.2 from 2026-09-15, and the last push was the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zerodha/pykiteconnect on GitHub