Zerodha order modification order in transit Kite error OMS Kite Connect order status

The 'order cannot be modified as it is being processed' message on Kite

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

Key facts

Exact Kite message	Order cannot be modified as it is being processed
What it means	The order is in transit between Zerodha's order system and the exchange, so the modify request is locked out
Common real cause	The order has just executed or been cancelled while your modify window was still open
Web and app fix	Refresh the order window to see the updated status, then act on the true state
API fix	Retry after a short delay and fetch the order history to confirm the terminal status
Not an exchange rejection	It is an in-transit lock in Zerodha's OMS, not a permanent exchange-side error

The message “Order cannot be modified as it is being processed” on Kite means the order is in transit between Zerodha ’s order management system and the exchange, so the system locks out your modify request rather than act on a stale state. Most often the order has just executed or been cancelled while your modify window was still open, so there is nothing left to change.

It is not an exchange rejection and not a margin failure. It is a momentary lock in the broker’s order management system (OMS) while a previous instruction is still in flight. This article covers what the message says, the in-transit cause, why a refresh resolves it on the web and app, the order-history check on the Kite Connect API, and whether to wait or cancel.

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

You open the modify window on a pending order , change the price or quantity, and submit. Instead of accepting the change, Kite returns “Order cannot be modified as it is being processed.” The phrasing is exact about the cause: the order is being processed, meaning an instruction on it is already moving through the OMS toward the exchange, and a second instruction cannot be layered on top of the first while that is happening.

The message says nothing about whether the order is open, filled or cancelled. It only reports that the modify could not be applied at that instant. That is the source of the confusion: a trader reads it as “my order is stuck” when the order has often already reached a terminal state, executed or cancelled, in the moment between opening the modify screen and pressing submit.

Why the message appears: orders in transit and the modification lock

An order on Kite passes through Zerodha’s OMS before it reaches NSE or BSE, and again on the way back. Between the moment you submit a place, modify or cancel instruction and the moment the exchange acknowledges it, the order is in transit. During that window the OMS holds a lock on the order so that two instructions cannot race against each other. A modify request that arrives while the order is mid-transit is refused with “Order cannot be modified as it is being processed,” because applying it could send the exchange a contradictory or duplicate instruction.

The common real-world trigger is timing, not a fault. You open the modify window when the order is open. While the window sits open, the order fills or is cancelled. You then submit the modify against an order that no longer exists in a modifiable state, and the OMS returns the in-transit message because the status has moved on. Zerodha’s own guidance is direct: this error generally occurs when you attempt to modify an order that has already executed or been cancelled, and the fix is to refresh the page to see the updated status.

What to do on the web and app

The fix on Kite web and the mobile app is a refresh. Refresh the order window, then read the order’s true current status. Three outcomes are possible. If the order executed, there is nothing to modify; the trade is done. If the order was cancelled, there is nothing to modify; place a fresh order if you still want the position. If the order is still genuinely open, the in-transit window has passed and you can now modify or cancel it cleanly. Do not resubmit the same modify repeatedly without refreshing, because each attempt may hit the same stale state and tell you nothing new about where the order actually is.

The numbers and behaviour around the message

Item	Detail	Source
Exact Kite message	“Order cannot be modified as it is being processed”	Zerodha support, Kite error messages
Cause	Order in transit between the OMS and the exchange	Zerodha support
Common trigger	Order executed or cancelled after the modify window opened	Zerodha support
Web and app fix	Refresh the order window	Zerodha support
API success code	A 200 response means the request was placed with the OMS	Kite Connect documentation
API error code	400 indicates an InputException; anything other than 200 is an exception	Kite Connect documentation

The behaviour is set by the OMS design, so it is the same across every Kite surface and the Kite Connect API.

On the Kite Connect API

Through the Kite Connect API, the same lock surfaces as an exception rather than a 200 response. A 200 means the modify reached the OMS and its data field carries the order_id; anything other than 200 is an exception whose data field carries the message, and a 400 specifically indicates an InputException. When you receive the in-transit exception, capture the order history immediately, because the order may already be in a terminal state, COMPLETE or CANCELLED, even though a prior status still showed it open. Retry the modify only after a short delay and only against the confirmed status from the order history. For automated strategies the rule is to re-fetch order history and check for a status change before resending a modify, rather than firing modify requests a few seconds apart, which can return valid-looking responses while the OMS records no actual modification.

Why a modify is not the same as a fresh order

A modify instruction is heavier than a place instruction, which is why it is the one most exposed to the in-transit lock. A place creates a new order; a modify must find an existing order, confirm it is still in a modifiable state, and replace its price or quantity without losing its place in the time-priority queue at the exchange. Each of those checks happens against a live order that may be filling at the same instant. When the order moves to a terminal state mid-modify, the safest response from the OMS is to refuse the change rather than guess, so it returns the in-transit message. The practical lesson for an active trader is that a fast market makes this message more likely, not less: the quicker your resting order fills, the smaller the gap between opening the modify window and the order vanishing under you. On a fast-moving contract, cancelling and replacing can be cleaner than chasing the price with repeated modifies, because a fresh order sidesteps the modify lock entirely.

What this is not

This message is distinct from a true exchange rejection and from the modification-count limit. It is not a price-band or circuit-limit rejection, where the exchange refuses the price. It is not the “maximum number of order modifications exceeded” error, which is a hard cap on how many times one order may be modified, a different rule entirely. It is not an RMS rejection for margin, and not the no-trades market-order rejection. The in-transit message is temporary by definition: it clears the moment the order’s previous instruction settles, which is why a refresh, not a workaround, is the answer.

External references

References

Zerodha support, “Order cannot be modified as it is being processed”, and the guidance to refresh the order window because the order has likely executed or been cancelled (as of 21 June 2026).
Kite Connect Orders API documentation, 200 response carrying order_id versus exception responses, and the 400 InputException code.
Kite Connect developer forum, capturing order history immediately on the in-transit error and confirming the terminal status before retry (as of 21 June 2026).

Frequently asked questions

What does 'order cannot be modified as it is being processed' mean?

The order is in transit between Zerodha’s order management system and the exchange, so the system locks out a modify request to avoid acting on a stale state. Often the order has just executed or been cancelled while your modify window was still open.

How do I fix it on the Kite web or app?

Refresh the order window. The error usually appears because the order status changed after you opened the modify screen. The refreshed status shows whether the order executed, was cancelled, or is still open, and you act on the true state from there.

Is the order still live when I see this message?

It may or may not be. The message only tells you the modify request could not be processed at that instant. The order itself could be open, executed or cancelled. Refresh the order book or fetch the order history to find the real current status.

Should I wait or cancel the order?

Refresh first. If the order is still open and you no longer want it, cancel it; if it has already executed, there is nothing to modify or cancel. Do not fire repeated modify requests, since the order may already be in a terminal state the screen has not yet shown.

Why do I get this on the Kite Connect API?

The modify request reached the order system while the order was mid-processing, so the OMS returned the in-transit exception rather than a 200 success. Capture the order history immediately on the error, then retry after a short delay against the confirmed status.

Is this an exchange rejection?

No. It is an in-transit lock inside Zerodha’s order management system, not a permanent rejection by NSE or BSE. The order is not refused by the exchange; the broker is just declining to modify it while the previous instruction is still in flight.

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.