Rest Api with Aggregate example returns limited number of rows

[surfingkaka]

`with RESTClient(key) as client:
from_ = "2019-01-01"
to = "2019-02-01"
resp = client.stocks_equities_aggregates("AAPL", 1, "minute", from_, to, unadjusted=False)

print(f"Minute aggregates for {resp.ticker} between {from_} and {to}.")

count = 0
for result in resp.results:
    dt = ts_to_datetime(result["t"])
    #print(f"{dt}\n\tO: {result['o']}\n\tH: {result['h']}\n\tL: {result['l']}\n\tC: {result['c']} ")
    count = count + 1
    
print(count)

`
Minute aggregates for AAPL between 2019-01-01 and 2019-02-01.
5000

last row is ''2019-01-10 11:55'

is there something I am missing ?

[Stormy110]

Hi there, thank you for reaching out! You can increase the number of results by using the limit parameter. The base limit is in minutes when querying minute bars and the max limit is 50,000. You can add limit=50000 to the query parameters and it should return the full set of data.

[surfingkaka]

Thank you. I assume to query more than 50K, one has to manage the repeat calls ? if so, please close this issue as resolved.

[rterbush]

I had this same question regarding management of a paged response. Doesn't appear that the aggregate API calls support the ability to manage a paged response as some of the other API calls do through a next_url parameter.

Could someone please enlighten me as to how we handle queries that span more than 50k results?

[Stormy110]

The aggregates endpoint does not have the next_url for pagination. Instead, if there are more than 50,000 messages in the response, you will need to query a smaller time frame of data. I recommend querying 1 months worth of minute bars per query.

[WillJDunn]

I noticed this same problem, that you cannot access the 'next_url' from the data returned from get_aggs() with the polygon RESTClient library or do any operations with it. However, it is still contained in the data you get, so I chose to parse the get_aggs() return data for the 'next_url' (url containing the cursor) and then executed a normal HTTP request to that URL to get the next page of data. Not ideal, but it results in far fewer requests than querying one month at a time as recommended by some others.

The largest monthly dataset I found from the past 2 years of data was only 18956, and there are numerous stocks that have far less. Getting the results 50000 at a time was far more efficient (I did try both).