Describe the bug
replace_order_by_id from the Alpaca Python SDK started failing a few days ago with error code 40310000 ("insufficient qty available for order") when attempting to update the limit price of an existing options order. The quantity requested matches the existing order quantity exactly, so no new quantity is being requested. The same replacement also fails through the Alpaca UI ("Could not replace order"), suggesting a backend issue rather than an SDK/code problem. The code has been unchanged for months and was working correctly until recently.
To Reproduce
- Open a calendar spread position (e.g. SPY puts)
- Place a closing order for the spread with an unrealistic/unfillable limit price
- Attempt to adjust the limit price of the closing order via:
a. The Alpaca web UI (Edit Order), or
b. The Python SDK using replace_order_by_id:
Code:
trade_client.replace_order_by_id(
order_id=existing_order.id,
order_data=ReplaceOrderRequest(limit_price=limit_price),
)
- Observe error:
insufficient qty available for order (requested: X, available: 0)
Reproduced on both live and demo accounts.
Expected behavior
The order's limit price should be updated without any quantity validation errors, since no quantity change is being requested. This was the working behavior prior to the last few days.
Screenshots
N/A — error log examples:
SDK error response
Replace failed for SPY260305P00686000/SPY260306P00686000: {"available":"0","code":40310000,"existing_qty":"15","held_for_orders":"15","message":"insufficient qty available for order (requested: 15, available: 0)","related_orders":["6bf82cd1-47b2-406c-bcac-65462f45402e"],"symbol":"SPY260305P00686000"}
2026-03-05 15:32:22,767 - Replace failed for SPY260305P00692000/SPY260306P00692000: {"available":"0","code":40310000,"existing_qty":"19","held_for_orders":"19","message":"insufficient qty available for order (requested: 19, available: 0)","related_orders":["b929c518-e221-4469-918b-224d96d3974f"],"symbol":"SPY260305P00692000"}
2026-03-05 15:47:14,353 - Replace failed for SPY260310P00687000/SPY260313P00687000: {"available":"0","code":40310000,"existing_qty":"9","held_for_orders":"9","message":"insufficient qty available for order (requested: 9, available: 0)","related_orders":["0026ea24-42e0-42a8-8296-187240390cfa"],"symbol":"SPY260310P00687000"}
Web UI error message
Error: Could not replace order. There was a problem trying to replace your order. Please try again.
Desktop
- OS: Linux & MacOS
- SDK: alpaca-py (Python)
- Account type: Live & Demo
Additional context
Workaround in place: cancelling the order, polling until cancellation is confirmed, then placing a new order. This works but is less clean than a replace. The issue also reproduces through the Alpaca web UI, pointing to a backend regression rather than an SDK or client-side issue.
Describe the bug
replace_order_by_idfrom the Alpaca Python SDK started failing a few days ago with error code40310000("insufficient qty available for order") when attempting to update the limit price of an existing options order. The quantity requested matches the existing order quantity exactly, so no new quantity is being requested. The same replacement also fails through the Alpaca UI ("Could not replace order"), suggesting a backend issue rather than an SDK/code problem. The code has been unchanged for months and was working correctly until recently.To Reproduce
a. The Alpaca web UI (Edit Order), or
b. The Python SDK using
replace_order_by_id:Code:
trade_client.replace_order_by_id(
order_id=existing_order.id,
order_data=ReplaceOrderRequest(limit_price=limit_price),
)
insufficient qty available for order (requested: X, available: 0)Reproduced on both live and demo accounts.
Expected behavior
The order's limit price should be updated without any quantity validation errors, since no quantity change is being requested. This was the working behavior prior to the last few days.
Screenshots
N/A — error log examples:
SDK error response
Web UI error message
Desktop
Additional context
Workaround in place: cancelling the order, polling until cancellation is confirmed, then placing a new order. This works but is less clean than a replace. The issue also reproduces through the Alpaca web UI, pointing to a backend regression rather than an SDK or client-side issue.