I am doing some back-tests and I am facing a problem with the “Bars API” for quotes before 08-25-2022. For the ‘TSLA’ symbol the returned values are terribly wrong, as you can see here:
06-02-2022 - Alpaca - o:732.47 h:792.63 l:726.20 c:775.00
06-02-2022 - Tradingview - o:244.16 h:264.21 l:242.07 c:258.33
06-03-2022 - Alpaca - o:729.68 h:743.39 l:700.25 c:703.55
06-03-2022 - Tradingview - o:243.22 h:247.80 l:233.42 c:234.52
08-24-2022 - Alpaca - o:892.69 h:910.94 l:889.50 c:891.29
08-24-2022 - Tradingview - o:297.56 h:303.65 l:296.50 c:297.10
08-25-2022 - Alpaca - o:302.36 h:302.96 l:291.60 c:296.07
08-25-2022 - Tradingview - o:302.36 h:302.96 l:291.60 c:296.07
Is there a way for you to fix that, or will the values always be wrong for old bars from a specific date? If this issue was already found, could you tell us a date from when we can really believe in old bars data?
Another question: is the issue specific to some symbols or does it happens to all symbols?
@Prometeus The Alpaca data for TSLA is correct. What you see are the actual prices of the stock on each specific day (ie what one would have traded at). The issue is there was a 3:1 stock split effective 2022-08-25 (see here). The split increased the number of outstanding shares by 3x and therefore effectively reduced the price by 1/3 after the split. That is why all the prices before 2022-08-25 seem to be 3x too large.
Alpaca by default returns ‘raw’ or unadjusted prices. Tradingview apparently defaults to ‘adjusted’. One can request adjusted prices by including the parameter
adjustment='split'. See the docs here. The adjusted data should match Tradingview.
Thanks, Dan! I had read the API documentation. Although I have some decades coding, I started coding for trading just one and a half years ago, and I was not aware of that ‘split’ subject. Perhaps it would be a good idea (even for reducing the support demand) to include details for some parameters, like that one. The ‘adjustment=split’ did the trick. I wonder if some trading algorithm that needs to calculate some indicators with past bars values can work well using bars values that are not at the same “base”.
@Prometeus Good suggestion to put information about adjustments in the API docs. In general, for trading signals, one would always want to use “split” adjusted data. If not, any split will look like a big price jump and probably mess up the signal calculation. There are of course exceptions but that is typical.
Less frequently, one would use “dividend” or “all”. That is really used most often to compare net gain from longer term holdings (ie more than 3 months). Consider two stocks which each have a 1% gain (ie split adjusted end_price/start_price) but one has a .5% dividend. If one was planning on holding the stock (at least until the next dividend) then, without adjusting for dividends, they would look equivalent. However, adjusting for both splits and dividends would show the dividend paying stock to have a 1.5% gain.
Thanks again for clarifying, even more, this point! I am sure it will help other users as well!
@Dan_Whitnable_Alpaca ,thank you so much for the clarification… I’m having a similar issue, however the split wasn’t sufficient. High value seems to be way off from the actual value from other places.
historical_data = api.get_bars(symbol, tradeapi.TimeFrame.Minute, start=start_time, end=end_time, adjustment="split").df
The highest value from 7AM EST to 9:30EST for symbol ATOM at 8:20AM is $9.2 while the one before and after are around $7
Name: 2023-04-27 12:20:00+00:00, dtype: float64
By any chance am I doing something wrong or is it possible there is a possibility of bad value ?
I wonder if there was a glitch in the systems, because also tradingview is missing values around 8:20AM EST on 4/27/23.
Here is screenshot from get_bars, it looks like its skipping 8:19 and 8:21
Thanks in advance.