We want developers to create compelling user experiences, but we also want the Nest service and devices to always be available for the user. Works with Nest 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 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. If you're using the Firebase client, you shouldn't hit these limits, as a single connection can handle all communication over a long period of time.
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 the supported Firebase SDKs (Web, iOS, and Android), rate limit violations appear as an error status when attempting to set a value, and will have description error text in the response message. If using the REST or REST Streaming clients, you will receive a response code of 429 Too Many Requests.
Handling 307 redirects
When making REST or REST Streaming 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.
This call uses the original base URL:
HTTP/1.1 307 Temporary Redirect Content-Type: application/json; charset=UTF-8 Access-Control-Allow-Origin: * Cache-Control: private, no-cache, max-age=0 Location: https://firebase-apiserver02-tah01-iad01.dapi.production.nest.com:9553/auth=c.FmDPkz... Connection: close Content-Length: 0
For the next and future calls, you would use the new host and port number:
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 limits and the Nest Home Simulator
Because we set a very high tolerance in virtual devices, your product is not likely to encounter data rate limit error conditions when using the Nest Home Simulator.
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.