Kite Connect Pricing and API Rate Limits (2026 Guide)

Reviewed: 14 August 2026

Kite Connect’s Personal plan is free for order, GTT, alert, margin and portfolio APIs. The Connect plan is ₹500 per month per API key and adds realtime WebSocket market data plus historical candle data. The documented REST limits are 1 quote request per second, 3 historical-candle requests per second, 10 order placements per second and 10 requests per second for other endpoints.

Those per-second limits are only part of the design. Zerodha also documents 400 orders per minute, 5,000 orders per day for a user/API key, and no more than 25 modifications to one order.

Kite Connect pricing in 2026

The paid plan bundles realtime and historical data; there is no separate historical-data subscription. Pricing can change, so check Zerodha’s product page before paying or renewing.

Official Kite API rate limits

Additional documented order controls are:

• Maximum 400 orders per minute.
• Maximum 5,000 orders per day for one user/API key across segments and order varieties.
• Maximum 25 modifications to one order; after that, cancel it and place a new order if appropriate.

These are ceilings, not performance targets. Sending exactly ten requests on a local clock boundary can still produce a 429 Too Many Requests response because client and server windows are not guaranteed to align.

Do not poll REST quotes as a live price feed

The quote endpoint is designed for snapshots. For continuous prices, use the WebSocket feed included with the Connect plan. The official documentation currently allows up to 3,000 instrument subscriptions on one WebSocket connection and up to three connections for a single API key.

A resilient service keeps one controlled market-data connection, distributes ticks internally, and reconnects with backoff. Opening a separate socket for every strategy wastes connections and creates inconsistent state.

How to handle a 429 response

1. Stop sending requests in that rate-limit bucket.
2. Record the endpoint, time, API key identifier and response without logging secrets.
3. Wait with bounded exponential backoff and a small random delay.
4. Retry only idempotent reads automatically.
5. For an order request, check the order book before retrying; a timeout or lost response does not prove the order was rejected.
6. Reduce concurrency or repair the shared limiter before resuming.

Never retry an order placement in a blind loop. Give each order intent a stable internal ID and persist its state before calling the API. If the outcome is uncertain, reconcile with the broker before sending another order.

Rate limiting when several workers share one API key

A limiter inside each process is not enough when several workers use the same key. Four workers that each stay below ten requests per second can exceed the combined limit. Put the counters in a shared service or route all Kite calls through one gateway.

Use separate buckets for quotes, historical data, orders and other calls because their documented limits differ. Track the minute and daily order totals independently. Leave headroom for manual risk actions such as cancelling or modifying an order.

Can you test without live money?

Kite’s current documentation includes a sandbox at sandbox.kite.trade with demo credentials. Use it to test supported request flows and error handling without a real account. The documentation states that the sandbox follows production rate limits.

A sandbox cannot reproduce every production condition. Before live use, also test session expiry, reconnects, duplicate events, partial fills, rejected orders, network timeouts and a restart while an order is pending.

What each common error means

• 400: request parameters or values are missing or invalid.
• 403 / TokenException: the session has expired or become invalid; clear the session and complete login again.
• 429: too many requests; pause and repair the request rate.
• 502: the API could not communicate with the order-management system.
• 503: the service is unavailable.
• 504: the API gateway timed out.

Treat a transient server or network error as an unknown outcome when an order may have reached the broker. Reconcile first; retry second.

Implementation checklist

1. Choose Personal if you only need account and execution APIs; choose Connect if you need live or historical market data.
2. Keep the API secret on the server and out of Pine scripts, browser code, webhook URLs and logs.
3. Use WebSockets for streaming prices and REST for snapshots and transactions.
4. Apply shared, endpoint-specific rate limits with safety headroom.
5. Persist order intent before sending and reconcile uncertain outcomes.
6. Handle daily login/session renewal as an explicit workflow.
7. Test failure cases in the sandbox and paper workflow before live orders.
8. Monitor 429 responses, reconnect count, rejected orders, queue delay and duplicate-block events.

For the authentication and session flow, continue with the secure Kite Connect integration guide. If the signal starts in TradingView, read the TradingView-to-Zerodha webhook guide.

Primary sources

• Zerodha Kite Connect product and pricing page
• Kite Connect exceptions and rate limits
• Kite Connect WebSocket documentation
• Kite Connect sandbox documentation

Planning an integration? Start with the endpoints, expected peak request rate and failure policy. A useful review should identify operational risks; it should not promise profitable trades or uninterrupted execution.