Http 429 error from cloud API

I have recently experienced http 429 error - The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes. Is there a rate limiting scheme in place - I haven’t found anything in documentation of the Cloud API - this was using get.

I’m not aware of any rate limiting docs. That said, how often were you polling? I can imagine you were pushing the limits of being a good netizen if you are to receive this error. Generally, once a second if already quite fast. If you need data more frequently, it might be good to look into a direct connection, both to not burden to cloud with excessive request and to eliminate the lag you’d ultimately receive by going through the cloud.

I am having the exact same problem.

When polling information from Particle I am getting loads of 429 “Too many requests.” Has something changed?

I am running the exact same code as before…


The same question goes for you, how often are you polling?
Often times people poll much too preferentially, just because they can. That doesn’t mean you should. Requesting a variable thousands of times per second not only doesn’t make sense, but it won’t do any good either.

To add onto that in respect to …

depending on others hitting the same endpoint your “misbehaviour” as a netizen might (can) be tolerated or not.

1 Like

Small log of the calls:

Call 21/09/2016 11:27:25
Call 21/09/2016 11:27:22
Call 21/09/2016 11:27:14
Call 21/09/2016 11:27:11
Call 21/09/2016 11:27:07
Call 21/09/2016 11:27:02
Call 21/09/2016 11:26:59
Call 21/09/2016 11:26:53
Call 21/09/2016 11:26:48
Call 21/09/2016 11:26:46
Call 21/09/2016 11:26:43

I have raised a ticket with Particle Support and had a fast reply from Rick

There is throttling being applied to get requests. The ‘polling’ referred to was not at a rate where one would expect to get this response and was no where near the throttle level (30 per second) but not documented, not set in stone and can vary!

My concern is that when scaling the solution I am working on is that the simple polling approach being used by my Web App developer will not work. So I will be looking at another approach - essentially, the device publishing when variables are updated or every 10 seconds say and the web app will get when a specific update is required - i.e. just before a Post to ensure the device is in a state to accept the function call.

Thanks for responses and I am not intending to be a ‘bad’ netizen!

That’s actually the better way of doing things. Just polling for the heck of it doesn’t make much sense, whereas publishing on an actual change is much more meaningful. You can still poll when specifically needed, such as first load, which is of course justified. It’s the best of both worlds :smile:

I also noticed some anomalies. I am doing of one variable reading every 5 sec, and send Publish every 60 sec.
Before even reading with an interval of 1 sec I had no problem.

Sorry for reviving this old thread but it didn’t seem to warrant a new thread and it does link in with this thread. I got the 429 error for the first time yesterday when trying to compile locally via the CLI. Didn’t realise that by iterating fairly often locally I could be abusing the API. Unless it was just an anomaly. It’s certainly made me more hesitant about iterating.

There might be a misconception. particle compile does not compile locally.
It’s still a cloud compile.

Ah. Thanks @ScruffR. I might have to reassess how I “code”. I find if something doesn’t work quite how I want it (or if I overlooked something) I fairly quickly make a small change recompile. It’s how I used to do it for the Arduino and it’s a bad habit, no doubt.