The Google Sheets API is a shared service, and we apply quotas and limitations to protect the overall performance of the Google Workspace system for all users.
Quota limits
While Sheets API has no hard size limits for an API request, users might experience limits from different processing components not controlled by Google Sheets. To speed up requests, we recommend a 2 MB maximum payload.
Sheets API has per-minute quotas, and they're refilled every minute.
For example, there's a read request limit of 300 per minute per project. If your
app sends 350 requests in one minute, the additional 50 requests exceed the
quota and generates a 429: Too many requests HTTP status code response. If
this happens, you should use an exponential backoff algorithm.
After 1 minute, you can execute requests again.
The following table details the request limits:
| Quotas | |||||
|---|---|---|---|---|---|
| Read requests |
|
||||
| Write requests |
|
||||
For details about file limits, see Files you can store in Google Drive.
Behavior and limitations
As you work with Sheets API, note the following behavior and limitations that affect your quotas:
Read requests are calls to any method that retrieves data from a spreadsheet, such as
getorsearch. Write requests are calls to any method that changes a spreadsheet, such asupdate,clear, orcopyTo.Users can submit multiple requests at the same time, as long as they're within the quota limit. Each batch request, including any subrequest, is counted as one API request toward your usage limit.
All Sheets requests are applied atomically. That is, if any request is not valid then the entire update is unsuccessful and none of the (potentially dependent) changes are applied.
There's a maximum time limit for processing one API request. When Sheets processes a request for more than 180 seconds, the request returns a timeout error.
Provided that you stay within the per-minute quotas, there's no limit to the number of requests that you can make per day.
Resolve time-based quota errors
For all time-based errors (maximum of N requests per X minutes), we recommend your code catches the exception and uses a truncated exponential backoff to make sure your devices don't generate excessive load.
Exponential backoff is a standard error handling strategy for network applications. An exponential backoff algorithm retries requests using exponentially increasing wait times between requests, up to a maximum backoff time. If requests are still unsuccessful, it's important that the delays between requests increase over time until the request is successful.
Example algorithm
An exponential backoff algorithm retries requests exponentially, increasing the wait time between retries up to a maximum backoff time. For example: