From what I can tell there is no method to support trailing stops ? I would like to be able to use order replacement to update the stop price on the stop order portion (the stop loss) of a bracket order.
Correct, trailing stop is not yet supported in our backend. That said, we are looking into it. Thanks for showing your use case where you would combine it with bracket orders.
I am also interested in using Trailing stops. I am looking forward for them to be implemented.
@hitoshi also, Tradingview’s panel with Alpaca does not even show brackets yet. Do you know why? are you able to help with a rough time frame brackets and trailing stop will be implemented for Tradingview? How about implementing
Not having these basic functionalities with Alpaca is quite frustrating for your Tradingview customers as nearly all other brokers on Tradingview (and yes even Robinhood has trailing buy/stop) have this stuff implemented.
Someone asked in Dec 2019 about this as well and there was no response.
Thanks for your help.
I’d also like to throw my support in here. Before I ever started trying to code anything up, I met with a good friend from college who’s been a full time trader at one of the big prop trading firms in Manhattan for over a decade to learn how humans do it before trying to program a computer to tackle the problem. He clued me into trailing stops, and how key they are to a huge number of trading strategies. Implementing them on our end though is super cumbersome… constantly having to replace standing stop orders and overwriting them with new values calculated from trade streams is just too much of a headache. Plus, if we lose connectivity or our programs freeze, we could lose money. Trailing stops really need to be implemented on Alpaca’s end to work properly and also to ensure we have at least a bit of a contingency in place if something goes wrong with our program.
I’d personally prioritize this above the feature request I submitted last week regarding contingency “close all open positions” measures simply because this at least gets us some of that, but also because it’s a key tool that many traders use. However, I do really hope you guys implement some other contingency measures too… at least something that closes all remaining open positions at like 3:55 or something like that in case all else fails.
Perhaps what you could do is combine this functionality. Trailing stops that close out at the end of the day automatically…
Great addition to the conversation, server-side implementation of trailing stop loss is a lot less risky than client side due to latency and transmission issues, that’s for sure.
@Kyle_Archie As far as close all positions, I don’t know what SDK you’re using but the API is equipped to close all positions in a single call. See Positions. We have an function that uses that endpoint in AlpacaforR .
Yes, I’m aware I can close all positions myself in one line of code. That’s great, except it doesn’t work if my program crashes, my system freezes, or i lose connectivity to Alpaca for whatever reason and get stuck holding positions on margin at market close… I want something as a fallback plan running on Alpaca’s server so I don’t have to sit there watching my code run or check in on it at 3:50 every day in case something went wrong. Sure, I could setup a dedicated EC2 instance or something that just runs “close_all_positions” or whatever the command is each day at a set time, but again, that’s not as error proof as having something run on Alpaca’s end, and I’m sure I’m not the only one who would use it if it was available as a fallback. Adding an option to make trailing stops get triggered at an expiration timestamp regardless of whether they hit the stop price seems like it would give us an extra safeguard for little extra dev work. @synchronicity
@Kyle_Archie Ah, for sure. Everything from the client side is subject to packet loss or transmission failure. That’s for sure. Forgive me, I hadnt actually searched for a post by you about close all positions, and I assumed you were thinking that functionality didn’t exist, which shaped my answer.
I don’t know why Alpaca has not implemented a trailing stop loss feature, seeing as how the contract with polygon and streaming data it allows would enable them to do so fairly easily in the same fashion that any client would. I definitely hope it’s in their dev pipeline.
it’s cool. Sorry if I came off brash… it’s just every week I seem to encounter a new bug / situation that I never encountered in my previous months of testing, and I’m just eager to see some more safety protocols get added on the backend and this order type I believe is a bit more resilient against outages and other issues than having to rely on my code to cancel open orders and replace them with new ones.
It’d be awesome if Alpaca shared their roadmap. I’ve seen a lot of people ask for trailing stops on Slack over the past several months. If we knew it was on the roadmap with a rough ETA, I think it would make a lot of people happy.
Bracket orders in TradingView and trailing stop support are by large top featue requests today. We are prioritizing our effort and will hopefully come back soon.
@hitoshi any updates on when can users expect tradingview bracket order integration? trailing stop loss?
@hitoshi I’m having some challenges with generating a manual trailing stop loss too. Is there any timeline or roadmap for this release?
Support trailing support would be very useful for algo tradings
Is it any update on trailing stop on orders ? I think is a must feature to be implemented !!!
This is critical and would love to see it soon!
User-generated trailing stops are difficult to implement and have a lot of limitations and need prohibitively frequent updates.
@hitoshi: Any updates on this important feature?
Any update on this? This will help a lot.
I setup a business account with alpaca and am patiently waiting for trailing stops. Is there a reason the majority of users are requesting it for months and months and months and it still is not implemented? I also agree an auto sell feature at the end of the day would be nice.
Please let us all know!!
It looks like when placing an order via the API, the return includes:
'trail_percent': None, 'trail_price': None,
I don’t see any documentation in the API Docs that explain how to use this so it may not be fully released / available yet.