We want developers to create compelling user experiences, but we also want the Nest service and devices to always be available for the user. Products that make a large number of requests in a given period of time can impact service and device availability, so we apply rate limits. Rate limiting restricts the number of API calls for a given time period.
Types of rate limits
We have implemented two classes of rate limits. The first limits are per device or structure per hour. These limits are shared across all Works with Nest products, and are intended to prevent overutilization of devices. The second class of limits are per access token. These limits are designed to prevent overutilization of the Nest service.
Per device/structure limits
Every write to the data model requires the device to wake up and synchronize state. This can impact battery life, so we limit the number of writes to devices and structures. We also monitor the battery state of all devices. If they drop below a certain threshold, we will reject write requests until the battery has recharged.
Per access token limits
Each access token also has an associated rate limit. Establishing connections to the service incurs some overhead, so we limit the number of connections a product can make in a specific time period.
For REST and REST streaming calls, each access token has a limited number of calls. Data rate limits apply to read/write calls via REST, and on read calls via REST streaming. To avoid errors, we recommend you limit requests to one call per minute, maximum.
When using REST you will receive a response code of 429 Too Many Requests.
Handling 307 redirects
When making REST calls, your product will need to handle 307 redirects. Also known as URL forwarding, a 307 Temporary Redirect response provides a new URL for the browser to resubmit a request.
When a 307 redirect happens, you'll need to make the call again with the new URL information. When you do this, you should cache the host and port number for use in future calls with that user/access token. Remember, each call counts toward the rate limit. Consider how your user is interacting with your product. Some users will press a button or choose a setting repeatedly, so if you make a call for every user action, it can impact rate limits very quickly. If a user makes a series of changes in rapid succession, you should only make an API call for the last (most recent) value.
For more information and an example, see How to Handle Redirects.
After 307 redirect
If you are using the redirect URL information and get a 307 redirect at a later time, you should follow that redirect.
If you are using the cached URL information and get a connection error (due to host out of service or site down), you should revert to the original base URL.
Rate limit changes
As we learn more about usage patterns and their impact on the service we may find it necessary to modify rate limits. We strongly encourage you to build your products to use the minimum number of calls required to build a compelling user experience, and to deal with rate limit violations appropriately.