Is there a function to ONLY get the most recent bar for a given symbol using historical bar data (not websocket live data)? I understand get_bars is able to retrieve the most recent bars if passed timestamps through but trying to be more precise here.
@suraj One can use the latest_bar endpoint to get the last available bar (see the docs here).
There are a few things to be aware of
- this will return the latest minute bar (ie cannot be specified as any other timeframe)
- bars are only created if there are ‘valid’ trades - because of this, the latest bar may be several minutes old
- bars are created about 2-3 seconds after the minute - synch ones local clock to NIST time and poll a few seconds after each minute to get the latest bar. Polling sooner will return the previous bar.
One can also get the latest bar information, along with a lot of other data, by using the snapshot endpoint (see the docs here). That also includes the current quote information which may be more helpful than bar prices for some strategies.
Thank you that helps
Hi Dan,
Can you clarify how a “Valid” trade is calculated? This is causing an issue in my code I run the historical bars through some processes to calculate indicators, and because of missing bars, I get inconsistent behavior causing my script to trade incorrectly or miss trades.
@GainsOclock Basically, only certain trade types (specified by the trade ‘condition’) are used in the bar calculations. Each field, such as Open, Close, or Volume, filters by different conditions. The Close price for example, considers only a limited number of ‘typical’ trades while Volume includes almost all trades. Alpaca follows the guidance given by the Securities Information Providers (SIPs) in determining which trades to exclude from calculations. That guidance is on page 64 of the Consolidated Tape System (CTS) Specification and page 43 of the UTP Specification.
Below is a summary of trade conditions which exclude a trade from a close price.
| Feed | Tape | Condition | Description |
|---|---|---|---|
| CTS | AB | B | Average Price Trade |
| UTDF | C | W | Average Price Trade |
| CTS/UTD | ABC | 4 | Derivatively Priced |
| CTS/UTD | ABC | 7 | Qualified Contingent Trade (“QCT”) |
| CTS/UTD | ABC | 9 | Corrected Consolidated Close (per listing market) |
| CTS/UTD | ABC | C | Cash Sale |
| CTS/UTD | ABC | G | Bunched Sold Trade |
| CTS/UTD | ABC | H | Price Variation Trade |
| CTS/UTD | ABC | I | Odd Lot Trade |
| CTS/UTD | ABC | M | Market Center Official Close |
| CTS/UTD | ABC | N | Next Day |
| CTS/UTD | ABC | P | Prior Reference Price |
| CTS/UTD | ABC | Q | Market Center Official Open |
| CTS/UTD | ABC | R | Seller |
| CTS/UTD | ABC | T | Form T |
| CTS/UTD | ABC | U | Extended Trading Hours (Sold Out of Sequence) |
| CTS/UTD | ABC | V | Contingent Trade |
| CTS/UTD | ABC | Z | Sold (out of Sequence) |
That being said, there will always be ‘missing bars’. The typical way to handle this, if your indicators require a value for each bar, is to forward fill all the bars. This can be done easily in python using the pandas resample method. Do realize however by forward filling one is adding ‘fake’ data. The best approach of course is for your indicators to handle missing bars ‘gracefully’ and correctly calculate the indicator using the data available.
1 Like