Limit must be large enough to compute an aggregate bar

Alpaca Market Data
1

I am getting “limit must be large enough to compute an aggregate bar” when I am trying to hit
https://data.alpaca.markets/v2/stocks/aapl/bars?timeframe=1Hour&limit=50&start=2021-04-01T00:00:00Z&end=2021-04-03T00:00:00Z

but if I change the timeframe to 1Day then it work
https://data.alpaca.markets/v2/stocks/aapl/bars?timeframe=1Day&limit=50&start=2021-04-01T00:00:00Z&end=2021-04-03T00:00:00Z

Any Idea???

2

Hey @Junior - sorry for the delay in someone getting back to you.

What’s happening here is intended functionality - a bar requires a certain amount of data in order to be able to populate accordingly.

When you call the 1 Hour timeframe, you’re generally going to want to limit your start + end times to be within a few hours of each other; a full two days simply won’t populate. That’s why this query works when you shift it to 1Day for timeframe.

3

Hi @Mallory

Please where can I find risk tolerance documentation? I want to group users into asset risk level for investment

4

Hey @developer - you’ll have to be a bit more specific here as to what you’re looking for. Thanks!

5

Hi, this isn’t clear for me.

I’ve been using the python API wrapper for about 1 day. It expects limit to mean the number of bars returned from the server. However, even if I’m just requesting 1 Bar in the 1 Hour timeframe, I still need to send a limit of 60 to successfully retrieve 1 Bar. Retrieving 32 bars in the 1 Hour timeframe (equivalent to 2 days) succeeds if I increase limit to 90.

I’ve succeeded at pulling two months of hourly bars (41 days’ worth) with a limit of 715.

Keep in mind that the python wrapper is breaking one request up into smaller chunks, so a number of chunk requests can succeed before the whole thing blows up at the end with “limit must be large enough to compute an aggregate bar.”

I haven’t experimented with using a variety of start dates, but if the underlying raw data can be of variable length per bar, there may not be a deterministic way to compute a length value that guarantees success. The best option appears to be to set a long length and hope it’s long enough to not throw an error.

If, however, the underlying data is 1-minute bars, an appropriate limit for the python wrapper could be (Number of expected 1 Hour bars) + (Number of 1-Minute data points in a 1 Hour Bar). For 2 Days, this would be (2 Days * 16 Hourly Bars per day) + (60 minutes per hour) = 92. In practice, I’d pad this further out of an abundance of caution…

It’s as if we’re telling the server how much working space will be needed to aggregate successfully.