I recently stared getting HTTP 429 errors. Is this a temporary glitch or did Alpaca recently add a rate limit for V2 API calls on the unlimited plan?
I am also on unlimited and I am also experiencing this.
I am experiencing this as well. I sent a support email to find out.
What I am seeing is things work in a terminal on hardware I own, however once deployed the very first (and all others after) api call returns 429 – even if its the only 1 sent. This is identical code as well. If this is something server side on their end sending back 429 as a catch all seems like a bad idea if that is what is happening here.
I’ll follow up if I get a reply. If I don’t get support I’ll just move onto another product.
Bump.
@oleg.rakhmatulin @Crystal_Xue_Alpaca
Receiving error: (on unlimited plan)
Too many open files in system (data.alpaca.markets:443)
@dynamic3 Do you use .NET SDK? If so how this error is reported to you - via the OnError
event of streaming client or somehow else?
Oleg, can you please provide some insight on how 429 is derived for unlimited plans? The documentation is limited and confusing.
Do we need to be adding a x delay between calls? IEX cloud, for example, requests a marginal delay between requests and upon establishing that it works fine. I did try this for Alpaca markets api with a generous .33 seconds between calls — same 429 error.
The 429 appears to be a catchall and its not a great error to default to unfortunately as its probably misleading.
Also, is there a possibility server side that Alpaca is not properly ascertaining if an api key is on the unlimited plan?
I essentially have this:
…
try{foreach(var alpaca_symbol in symbols)
{
var bars = await client.ListHistoricalBarsAsync(
new HistoricalBarsRequest(alpaca_symbol, from, into, BarTimeFrame.Day));
}
}catch(Exception ex)
{
Console.WriteLine("AlpacaError: {0} ", ex.Message);
}
…
The program is a .NET Core application running on Ubuntu/Linux. The error I mentioned is coming out of ex.Message (after about 5000+ successful requests back)
Unfortunately, I’m unable to tell you anything about the server side. AFAIR unlimited plan still has some rate limitations but I’m not sure and it would be better if you’ll ask Alpaca support about it.
By default, .NET SDK makes 3 attempts to call REST API and raise an exception only if all attempts will fail with some errors (for example with this rate limit error code). Unfortunately, throttling logic implementation on the client-side is not ideal and can potentially send many requests at once and hit the rate limit in a cycle. I’m working now on better client-side throttling but I don’t have any estimations for this work completed. In the meantime, you can increase the retry attempts for clients or add your own throttling if you can implement it better from your code side.
Do you have suggestions for a better way to grab historical data of all symbols? Would it be possible to get historical data via the socket connection? ie. i request bars from some start-end interval and the socket streams that to me like it would real-time.
would prefer to consolidate data-retrieval logic
Unfortunately, Alpaca streaming API works only with real-time data. No historical data streaming for now.
You can use new multi-symbol historical requests added ninth Alpaca Data API v2 recently. I’ve tested it for a really big symbols list and it works. The .NET itself has a URL size limit but you can always split the whole list of symbols into smaller subsets.