Modifying a Stoploss Order is NOT Working, despite the API returning SUCCESS status


I am using your python sdk for v2.0 but I can’t seem to modify the price and trigger_price fields programmatically even though your SDK returns status as ‘success’. Please see the attached screenshot, the stoploss order id is real and you can check it in your system as well. The very same price and trigger_price continue showing in the dashboard and the order also exits at those levels. Which means the stoploss order was not modified at all.

What’s wrong? Some bug in the SDK?

Kindly refer the attached screenshot and resolve this a.s.a.p. Let me know if you need something else from my end.


Even today (Sep/08), it’s the same issue:

BUY Order complete @331.70
SL order 230908025456317 placed. Trigger: 320.00, Price: 319.00

[15, 320.0]

modify to: {‘order_id’: ‘230908025456317’, ‘price’: 329.0, ‘trigger_price’: 330.0, ‘validity’: ‘DAY’, ‘order_type’: ‘SL’}

{‘data’: {‘order_id’: ‘230908025456317’}, ‘status’: ‘success’}

But nothing gets modified in real and in dashboard and real, it continues showing the earlier price/trigger_price.

Hi @Sheoran ,

Welcome to the Upstox community!

We are checking this with the concerned team, and they will get back to you soon.


Hi, any update on this? It’s been more than a week since I mailed your support about it.
I hope you understand it’s not my individual issue but an issue at your API level.


A fix related to the issue you highlighted is scheduled for release today.

Kindly review it by tomorrow.

Should any complications arise, we’ll reach out directly to ensure a swift resolution.

Thank you!


Could you give this a try and share your feedback?


Yes, I have tried. You can check the order_ids in your system, the main issue is resolved from the POV of operations. But two other issues have cropped up, as highlighted in points 1 and 6. It seems as if the API is fetching responses from some cache and not updating in REAL TIME. You kindly check on your side what it is:


1) Placed BUY Order and set out to check order_status with get_order_details using the returned order_id (because I can not place a SL order unless my order is complete), I get this response:

Exception in get_order_details for order_id 230912025593635: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({‘Date’: ‘Tue, 12 Sep 2023 06:01:21 GMT’, ‘Content-Type’: ‘application/json’, ‘Transfer-Encoding’: ‘chunked’, ‘Connection’: ‘keep-alive’, ‘Vary’: ‘Origin, Access-Control-Request-Method, Access-Control-Request-Headers’, ‘message’: ‘request failed’, ‘requestId’: ‘9c8de954-f734-488c-9ace-be13ede43496’, ‘X-Content-Type-Options’: ‘nosniff’, ‘X-XSS-Protection’: ‘1; mode=block’, ‘Cache-Control’: ‘no-cache, no-store, max-age=0, must-revalidate’, ‘Pragma’: ‘no-cache’, ‘Expires’: ‘0’, ‘Strict-Transport-Security’: ‘max-age=0; includeSubDomains’, ‘X-Frame-Options’: ‘DENY’, ‘CF-Cache-Status’: ‘DYNAMIC’, ‘Set-Cookie’: ‘_cfuvid=fj2USb9cC0V1xULzWLoV8uG_bFdpoamb4.e6hQKQEs4-1694498481812-0-604800000; path=/;; HttpOnly; Secure; SameSite=None’, ‘Server’: ‘cloudflare’, ‘CF-RAY’: ‘8055ef75ca3c3c04-BOM’})
HTTP response body: b’{“status”:“error”,“errors”:[{“errorCode”:“UDAPI100010”,“message”:“Order not found”,“propertyPath”:null,“invalidValue”:null,“error_code”:“UDAPI100010”,“property_path”:null,“invalid_value”:null}]}’

2) Regardless of exception above, we keep checking. Once order_status is complete, I get this response:

BUY Order complete @151.55

3) Then I place SL order for the same:

SL order 230912025593670 placed. Trigger: 115.00, Price: 100.00
[15, 115.0]

4) Then I try modifying the SL order with success (it’s now updating price and trigger_price in dashboard):

modify to: {‘order_id’: ‘230912025593670’, ‘price’: 112.0, ‘trigger_price’: 117.0, ‘validity’: ‘DAY’, ‘order_type’: ‘SL’}

{‘data’: {‘order_id’: ‘230912025593670’}, ‘status’: ‘success’}
SL Order modified

5) Then I again try modifying the SL order with success (it’s now updating price and trigger_price in dashboard):

modify to: {‘order_id’: ‘230912025593670’, ‘price’: 121.0, ‘trigger_price’: 140.0, ‘validity’: ‘DAY’, ‘order_type’: ‘SL’}
{‘data’: {‘order_id’: ‘230912025593670’}, ‘status’: ‘success’}
SL Order modified

6) Then I return the last object from get_order_details on the SL order but it doesn’t reflect the latest updated price and trigger_price, but the one before:

[{‘average_price’: 0.0,
‘disclosed_quantity’: 0,
‘exchange’: ‘NFO’,
‘exchange_order_id’: ‘1500000045934381’,
‘exchange_timestamp’: ‘2023-09-12 11:31:24’,
‘filled_quantity’: 0,
‘instrument_token’: ‘NSE_FO|44534’,
‘is_amo’: False,
‘order_id’: ‘230912025593670’,
‘order_request_id’: ‘2’,
‘order_timestamp’: ‘2023-09-12 11:31:24’,
‘order_type’: ‘SL’,
‘parent_order_id’: ‘NA’,
‘placed_by’: None,
‘price’: 112.0,
‘product’: ‘I’,
‘quantity’: 15,
‘status’: ‘trigger pending’,
‘status_message’: None,
‘tag’: ‘long’,
‘tradingsymbol’: ‘BANKNIFTY13SEP2345600CE’,
‘transaction_type’: ‘SELL’,
‘trigger_price’: 117.0,
‘validity’: ‘DAY’,
‘variety’: None}]


The discrepancy you observed in point 6 mirrors the one in point 1. If you call get_order_details immediately post placing or modifying an order, it may either fail or return outdated data since we might not have the latest updates at that instant.

We’re actively addressing this concern.

Moreover, it’s crucial for you to verify the status field in the response from get_order_details. Based on your data, the status shows as trigger pending, which isn’t the conclusive status for a modification action. The status progression for a modify action typically goes: trigger pending -> modify validation pending -> modify pending -> modified. Ensure you’re checking for the modified status to prevent potential issues in your app.

For the time being, until the concern with the get_order_details method is resolved, I’d recommend incorporating a systematic delay before its invocation.

I trust this clarifies your query.

Thank you!

Thanks, good to know that you are going to address it soon. The issue being that you are returning the order_id before your system has entry for it. The order_id, or any value, should be returned only once the system is capable of fetching data against it, even if intermediate.

For someone unaware of this bug, one has to continue checking in loop which results in a waste of rate limited API calls. As a stopgap arrangement, you may want to implement something like time.sleep or setTimeOut or sleep_for while the backend data is being readied.

What I am essentially trying to implement here is a trailing stoploss, since you have stopped supporting the OCO order type in your api v2.

Your second comment is a bit unclear. In my understanding, the final status of any open stoploss order, after any intermediate stages such as modified etc, should be “trigger pending” only. Because we may need to modify an open stoploss order multiple times. Are you saying the status of a modified stoploss order becomes “modified”, instead of “trigger pending”? Do we need to check for “modified” status and not “trigger pending” status, the second time we want to modify an open stoploss order?


You’re right regarding the status. The specific status you should be on the lookout for is trigger pending. I observed that you made two modify requests: the first at 11:31:24.689 AM for a price of 112.0 and the second at 11:31:26.857 AM for a price of 121.0.

This aligns with the ongoing issue we’ve been addressing.

We will update you as soon as we have a solution in place.