Supported protective-stop workflow for a partially filled DAY entry order

Alpaca Integration Applications
1

I am testing a personal U.S. equities system using an Alpaca paper account and need to understand the supported order lifecycle before running a controlled test.

The intended order is a BUY limit entry, DAY time-in-force, OTO order class, with a stop-loss child only (no take-profit leg). A filled position may be held overnight.

Alpaca’s current API and alpaca-py schemas expose one time_in_force on the OTO request, while StopLossRequest contains only stop_price and optional limit_price. The documentation also indicates that the attached exit order is not activated until the entry is completely filled.

That leaves three implementation questions.

Question 1: If the DAY entry partially fills, can a separate standalone GTC sell-stop be submitted for exactly the currently filled quantity while the unfilled remainder of the BUY order remains open?

Question 2: If additional shares subsequently fill, what is the supported race-safe workflow for increasing the protective-stop quantity, without leaving filled shares unprotected, without submitting a sell quantity greater than the actual position, without preventing the remaining BUY quantity from filling, and without creating duplicate stop orders? Should the existing standalone stop be replaced, or must it be canceled and resubmitted? Which trade_updates events and order fields should be reconciled before proceeding?

Question 3: Is this behavior and workflow identical in Alpaca paper and live U.S. equities trading?

If no gap-free supported workflow exists for this combination, that would also be useful to confirm explicitly.

I am looking for broker/API mechanics, not trading or investment advice. No order has been submitted for this question. An Alpaca staff response or a reproducible API sequence would be greatly appreciated.

2

@AWB I’ll try to answer your questions…

Question 1: If the DAY entry partially fills, can a separate standalone GTC sell-stop be submitted for exactly the currently filled quantity while the unfilled remainder of the BUY order remains open?
No. If the BUY entry order is still open, it implies that the associated stop-loss order is also still open. Submitting a second stop-loss order would effectively try to sell the same shares twice, since you already have an open order to sell them.

Question 2: If additional shares subsequently fill, what is the supported race-safe workflow for increasing the protective-stop quantity, without leaving filled shares unprotected, without submitting a sell quantity greater than the actual position, without preventing the remaining BUY quantity from filling, and without creating duplicate stop orders?
Since you are submitting an OTO order, the stop loss order will not be submitted and therefore not active until the initial by entry order fills complete. Any partially filled shares will be, as you stated “unprotected” until the initial by order fills complete and the stop loss order is submitted.

Question 3: Is this behavior and workflow identical in Alpaca paper and live U.S. equities trading?
The paper and live trading environments are identical in how OTO orders are processed.

A couple of comments. Partial fills are rare in live trading. However, partial fills are intentionally exaggerated a bit in paper trading to ensure algos see them and respond appropriately. I also avoid using the term “protective” stop and simply call it a stop order. I feel “protective” instills a false sense of security. A stop market order may or may not fill at the stop price. The order triggers at the stop price but then fills at the market price, which may be above or below it. Additionally, a single trade can trigger a stop order. The order fills around the stock price, but then prices can resume higher where they were. In these cases, a stop order is a great way to lock in your losses. A stop order is not a precision tool and, in some ways, is a relic of past manual trading. It wasn’t too long ago that, to sell a stock, you had to call your broker. A stop order was a way to help in those cases you couldn’t get to a phone very easily (think of the days before cell phones).

I would highly recommend using OTO orders, not with a stop order leg, but rather a take-profit leg. Have your algo constantly monitor your orders and positions, and current trades and quotes. Have your algo decide if any open positions need to be closed. To close the position, simply replace the take profit limit price with a marketable price. That will cause the limit order to execute immediately. Simplistically, your algo could monitor trades and implement a basic stop order. However, a more robust approach would be to monitor trades and quotes and do a bit of smoothing to ensure you really want to close the position.