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.