Zerodha order modification Kite error messages rate limit Kite Connect cancel and replace

Maximum allowed order modifications exceeded on Zerodha Kite

From WebNotes, a public knowledge base. Last updated 21 June 2026. Reading time ~9 min.

Key facts

Exact message	Maximum allowed order modifications exceeded
The cap	25 modifications per single order, across Kite web, the Kite app, and the Kite Connect API
What hits the limit	Each price or quantity change to a resting order counts as one modification; the 26th change is rejected
The fix	Cancel the existing order and place a new order; the count resets for the fresh order
Why the cap exists	It is a risk-management rate control that limits how often a single order can be amended, alongside the 5,000-orders-per-day cap

“Maximum allowed order modifications exceeded” is the message Kite returns when a single order has been modified the maximum number of times Zerodha permits, which is 25; the 26th modification request is rejected, and the documented fix is to cancel the existing order and place a new order instead. The cap is a per-order rate control, it applies identically on Kite web , the Kite app, and the Kite Connect API, and the modification count resets the moment you place a fresh order.

The message confuses traders because the order itself is valid and resting on the exchange; nothing is wrong with its price, quantity, or margin. The only thing exhausted is the allowance for how many times that one order may be amended. A trader chasing a moving price by repeatedly editing the same limit order, or an algorithm re-pricing a resting order on every tick, runs through 25 amendments quickly and then cannot edit further. This article states the exact cap, separates it from the adjacent 5,000-orders-per-day and “order being processed” controls it is often confused with, and gives the cancel-and-replace fix for both manual and API trading.

Conflict-of-interest disclosure. This guide is published by the WebNotes Editorial Team for informational purposes and is written independently. WebNotes operates a Zerodha account-opening referral programme, disclosed on the pages that carry the referral link; this guide does not carry it and earns no referral commission from the procedure described here.

What the message says

The exact wording is “Maximum allowed order modifications exceeded.” It surfaces in the order status notification on Kite the instant a 26th modification request is sent on the same order. The order it refers to remains live and unchanged at its 25th-modification state; the rejected request simply fails to take effect, so the order continues to rest at whatever price and quantity it held before the rejected attempt.

This is a modification rejection, not an order rejection. The order is not cancelled by hitting the cap; only the further edit is refused. A trader who misreads the message and assumes the order is gone may re-place it unnecessarily and end up with two live orders. Read the message precisely: it refuses the next edit, it does not unwind the order.

The cap is 25 modifications per order

Zerodha allows a maximum of 25 modifications per order. Each amendment to a resting order, a change to its limit price, its trigger price, its quantity, or its order type, counts as one of the 25. After the 25th successful modification, the order is locked from further editing, and the 26th attempt returns the message.

The cap is per individual order, identified by its order ID. It does not pool across orders: a second, separate order starts with its own fresh allowance of 25. It also does not pool across the day in the way the orders-per-day cap does; it is bound to the single order’s lifetime. An order placed in the morning, modified 25 times by noon, is locked for the rest of its life regardless of how many orders you placed elsewhere.

Zerodha documents the rule alongside its broader order rate limits: a single user or API key cannot place more than 5,000 orders per day across all segments and varieties, and a maximum of 25 modifications are allowed per order. The two numbers are different controls (covered below), but Zerodha publishes them together because both are order-rate risk limits.

Why the cap exists

The 25-modification cap is a risk-management rate control. A single order amended hundreds of times per second imposes load on the exchange’s order-management system and on Zerodha’s own gateway, and a runaway algorithm re-pricing one order on every tick can generate that load without ever placing a new order, so an orders-per-day cap alone would not catch it. Capping modifications per order closes that gap: it bounds the message rate a single resting order can generate.

The cap also nudges traders away from a poor execution habit. Chasing a fast-moving price by editing the same limit order 30 or 40 times is rarely better than cancelling and re-placing, and on a genuinely fast move it tends to leave the order trailing the market. The 25-amendment ceiling forces a cancel-and-replace once edits run high, which is usually the cleaner action anyway.

The fix: cancel and place a new order

Zerodha’s documented resolution is direct: you cannot modify the order beyond the limit, so cancel the existing order and place a new order instead. The replacement order is a distinct order with its own order ID, so it begins with a fresh allowance of 25 modifications. There is no waiting period and no ticket; the cancel-and-replace is immediate.

In practice the sequence is: cancel the locked order from the Orders tab on Kite, then place a new order at the price and quantity you intended. If you are managing the order manually, this costs one cancel and one new placement against your daily order count. If you find yourself hitting the 25-cap often on the same instrument, the underlying issue is usually that you are micro-managing a limit order in a fast market; consider a wider limit, a market order where appropriate, or a GTT for a price you want to wait for rather than chase.

On the Kite Connect API

The cap is identical on the Kite Connect API: a maximum of 25 modifications per order. An algorithmic strategy that re-prices a resting order on every market tick will exhaust the allowance in seconds, then receive the rejection mid-strategy, which can leave the order stranded at a stale price if the code does not handle the error.

The standard pattern is to track a modification counter per order ID and to cancel-and-replace before the 25th amendment rather than after the rejection. Maintain a count for each unique order ID, and once the count approaches the ceiling, cancel the previous order and place a fresh order at the current price, resetting the counter. Building the cancel-and-replace into the strategy, rather than treating the rejection as an exception to recover from, keeps the order live at the intended price without ever touching the cap. The full API order-rate behaviour, including the 5,000-orders-per-day limit, is in how to fix a maximum order request exceeded error .

How this differs from adjacent limits

Three controls carry similar-sounding messages and are routinely confused. Keep them separate.

The 5,000-orders-per-day cap limits how many distinct orders a single user or API key may place in a day, across all segments and varieties. It is about the number of fresh orders, not amendments to one order, and its message is “Maximum allowed order requests exceeded.” A trader can hit it without ever modifying an order, simply by placing too many. See how to fix a maximum order request exceeded error .

The 25-modifications-per-order cap, this article’s subject, limits how many times one already-placed order may be amended. Its message is “Maximum allowed order modifications exceeded.” It is bound to a single order’s lifetime, not to the day.

The “order cannot be modified as it is being processed” message is different again: it means a modification arrived while a previous request on the same order was still being processed by the exchange, a timing collision, not a count limit. The fix there is to wait a moment and retry, not to cancel and replace. See order cannot be modified as it is being processed .

Reading the exact message tells you which control you hit. “Modifications exceeded” means the 25-cap and a cancel-and-replace; “requests exceeded” means the 5,000 daily cap; “being processed” means a transient timing collision.

Common confusions

Thinking the order was cancelled. The cap refuses the next edit; it does not unwind the order. The order stays live at its last accepted state. Do not re-place it without first cancelling.
Confusing it with the 5,000-orders-per-day limit. “Modifications exceeded” is the per-order 25-cap; “requests exceeded” is the daily order-count cap. They are separate controls.
Confusing it with ‘being processed’. “Order cannot be modified as it is being processed” is a timing collision, fixed by waiting and retrying, not by cancel-and-replace.
Chasing a fast price by editing one order. Repeated micro-edits trail a fast market and burn the 25 allowance. Cancel and re-place, or use a wider limit or a GTT.
No error handling in an algo. An API strategy that re-prices on every tick exhausts 25 in seconds. Track the count per order ID and cancel-and-replace before the cap, not after the rejection.

External references

References

Zerodha support, “What does the ‘Maximum allowed order modifications exceeded’ error mean?” (accessed 21 June 2026), stating the 25-modification cap and the cancel-and-replace fix.
Zerodha support, “Why is the error ‘Maximum allowed order requests exceeded’ displayed?” (accessed 21 June 2026), 5,000 orders per day and 25 modifications per order.
Kite Connect v3 API documentation, exceptions and rate limits (accessed 21 June 2026).
SEBI (Stock Brokers) Regulations 1992 and exchange risk-management circulars on order-rate controls.

Frequently asked questions

What does 'Maximum allowed order modifications exceeded' mean on Kite?

You have modified a single order the maximum number of times Zerodha permits, which is 25. The 26th modification is rejected with this message. To change the order further, cancel it and place a new order instead, which resets the count.

How many times can I modify an order on Zerodha?

Twenty-five times. Zerodha allows a maximum of 25 modifications per order, across Kite web, the Kite app, and the Kite Connect API. Each price or quantity change to a resting order counts as one of the 25.

What should I do when I hit the order modification limit?

Cancel the existing order and place a fresh one. Zerodha’s documented fix is that you can cancel the existing order and place a new order instead. The new order starts with a fresh modification count of 25.

Why does Zerodha limit order modifications to 25?

It is a risk-management rate control. A single order amended hundreds of times in seconds loads the exchange and can mask algorithmic misbehaviour, so Zerodha caps modifications per order at 25, alongside the cap of 5,000 orders per day per user or API key.

Does the 25-modification limit apply to the Kite Connect API?

Yes. The cap is identical on the API: a maximum of 25 modifications per order. Algorithmic systems should track a per-order modification count and cancel-and-replace before the 25th amendment to avoid the rejection mid-strategy.

Is the modification limit the same as the 5,000-orders-per-day limit?

No. They are two separate controls. The 5,000-orders-per-day cap limits how many distinct orders one user or API key can place in a day. The 25-modification cap limits how many times one already-placed order can be amended.

Reviewed and published by

WebNotes Editorial Team

The WebNotes Editorial Team covers Indian capital markets, payments infrastructure and retail investor procedures. Every article is fact-checked against primary sources, principally SEBI circulars and master directions, NPCI specifications and the official support documentation published by the intermediary in question. Drafts go through a second-pair-of-eyes review and a separate compliance read before publication, and revisions are tracked against the SEBI and NPCI rule changes referenced in the methodology section.

Last reviewed: 21 June 2026
Conflicts of interest: WebNotes is independent. No relationship with any broker, registrar or bank named in this article.