When I signed up for my API key I was asked to limit requests to once every 1-10 minutes. Sounds reasonable, but given the upcoming demise of ThingSpeak, I need some clarification. Is the request rate limit 1 request per sensor every 1-10 minutes or 1 request from my API key every 1-10 minutes?
In my application I have several controllers in the field that poll a nearby sensor once/minute. So, I have 2 use cases for the API key: (1) to query a list of nearby sensors when a controller is configured and (2) once configured, “real-time” queries of the selected sensor’s data once per minute. In other words, each controller will query 1 sensor once per minute but there will be multiple controllers in the field so the overall rate from my API key will be higher.
So far I have been using ThingSpeak for the real-time queries but obviously that will have to change.
I’d like to know this too - currently I’m querying every 5 minutes for a single sensor, but would ideally like to query every minutes, providing it doesn’t generate excessive load.
Interesting, with the Thingspeak API, I was able to make multiple requests asynchronously and pull a full year’s worth of historical data in 3 seconds for PM hourly averages. Trying to do the same with the new api cause an internal server error, even after implementing delays. Hopefully someone knows about the rate limit.
My R script currently loops over a list of sensors with a 1 minute pause in between each API call, and that has not yet resulted in me being rate limited.
I also emailed contact@purpleair.com on this topic and for my scenario - multiple independent devices each querying their own nearby sensor, so worst case all back to back in a burst - the only way to avoid rate limiting is to use the groups feature of the API. So, clearly rate limiting is based solely on the API key and not the IP address or some other parameter.
They also promised to document the rate limiting more explicitly.
muhahahahah