PasteSheet icon PasteSheet logo mark — a spreadsheet grid with a curly brace on a green rounded square PasteSheet

Google Sheets API rate limits, explained

The Google Sheets API is generous until an app reads it on every request — then the quota bites and pages start failing. Here is how the limits work and how caching keeps you under them.

Last updated

Key facts

  • The Google Sheets API allows 300 read requests per minute per project and 60 per minute per user. Past that it returns 429 RESOURCE_EXHAUSTED. source
  • Write requests carry the same 300-per-project / 60-per-user ceiling as reads. source
  • The quotas are per minute, and they refill — they are a rate limit, not a monthly cap. Caching in front of the sheet removes the problem outright, because 10,000 visitors become one upstream read per TTL.
  • Google states that all standard use of the Sheets API is available at no additional cost — though it has said exceeding the quota is planned to incur Google Cloud charges later in 2026. source
  • A cached endpoint reads the sheet once per TTL, not once per request — so 10,000 visitors become one upstream read, and Google's quota stops being your problem.

How Google's quotas work

The Google Sheets API enforces per-minute read quotas scoped to your Cloud project and to each user (historically around 300 reads/minute/project and 60/minute/user, though Google tunes these). Go over and requests come back 429 Too Many Requests. The catch: the limit is on API calls, so an app that reads the sheet on every page view spends that budget fast.

Third-party spreadsheet-to-API services add their own, often much lower, free-tier caps on top — and some fail silently when you cross them, serving a blank page instead of an error.

The official numbers, in one place

These are the published per-minute read quotas. They are rate limits that refill every minute, not a monthly allowance you burn down:

Quota Limit Scope
Read requests per minute 300 Per Cloud project
Read requests per minute 60 Per user, per project
Write requests per minute 300 Per Cloud project
Write requests per minute 60 Per user, per project
Cost per request Free Standard use, no billing
Refill window 60 seconds Rolling

Which limit you are actually hitting

The two quotas fail differently, and knowing which one fired tells you what to change. The per-user limit of 60 reads/minute is the one a single service account trips, because every request your backend makes is attributed to that one identity — so it is the ceiling most server-side apps meet first, no matter how large the project quota is.

The per-project limit of 300 reads/minute is what you hit when many users are each authenticated separately, or when several services share one Cloud project. Splitting work across more service accounts raises the per-user ceiling but not the project one, which is why "add another service account" stops helping at a certain scale.

Both surface as the same error, so read the payload rather than the status code alone.

What the error looks like

Google returns 429 with a RESOURCE_EXHAUSTED status. If you are seeing this string in an editor, a CLI, or an agent — including inside tools like Cursor — it is this quota, not a bug in your code:

response
{
  "error": {
    "code": 429,
    "message": "Quota exceeded for quota metric 'Read requests' and limit
                'Read requests per minute per user' of service
                'sheets.googleapis.com'",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Why apps hit the wall

  • Reading the sheet live on every request instead of caching the result.
  • Traffic spikes — a launch or a crawler multiplies reads in a single minute.
  • A low free-tier cap on a hosted service that you quietly exceed.
  • Polling on a timer — a 5-second refresh in ten open browser tabs is 120 reads a minute on its own.
  • Retrying on failure without backoff, which turns one 429 into a stampede.
  • No visibility: many setups fail blank rather than returning a clear 429.

Fixing it, in order of payoff

Work down this list — the first step usually ends the problem outright:

  1. 1 Cache the read. Serve from a cached copy with a TTL instead of calling Google per request. One read per TTL replaces one read per visitor, and that is a change of orders of magnitude, not percentages.
  2. 2 Batch your ranges. If you must call Google directly, use spreadsheets.values.batchGet to fetch several ranges in one request rather than one call per range.
  3. 3 Back off on 429. Retry with exponential backoff and jitter. Retrying immediately guarantees a second 429.
  4. 4 Stop polling on a timer. Refresh on demand, or lengthen the interval until it fits inside 60 reads a minute across every client.
  5. 5 Request a quota increase in the Google Cloud console — worth doing, but slow, and it does not help the per-user ceiling.

How caching removes the problem

PasteSheet reads Google once and serves everyone else from an edge cache, so a thousand visitors in a minute is one read from Google, not a thousand. The quota stops being something you manage, because you are no longer near it — the upstream read rate is fixed by your TTL rather than by your traffic.

When you do reach your plan's limit, you get an explicit 429 with rate-limit headers telling you what to slow down to — never a silent blank page. See how the caching layer works, what to do about an already-exceeded quota, how the cached endpoint fits into using Google Sheets as a REST API, or compare quotas across plans.

Frequently asked questions

What are Google Sheets API rate limits?

Google enforces per-minute read quotas per Cloud project and per user (roughly 300/min per project, 60/min per user). Exceeding them returns HTTP 429. Reading a sheet on every request spends that budget quickly.

How do I avoid hitting the rate limit?

Cache reads instead of calling the API on every request. PasteSheet reads Google once and serves everyone from an edge cache, so traffic spikes do not multiply into API calls.

What happens when I hit PasteSheet's limit?

You get a clear 429 with rate-limit headers telling you to slow down or upgrade — never a silent blank page. Per-minute limits range from 60 to 5,000 by plan.

What are the official Google Sheets API usage limits?

Google publishes 300 read requests per minute per Cloud project and 60 read requests per minute per user, with the same numbers applying to writes. They are per-minute rate limits that refill, not a monthly cap, and standard use carries no charge.

What does RESOURCE_EXHAUSTED mean in the Sheets API?

It is the status Google returns alongside HTTP 429 when you cross a per-minute quota. The message names the exact metric that fired — usually "Read requests per minute per user" — which tells you whether the per-user or per-project ceiling is the one you hit.

Is the Sheets API rate limit per user or per project?

Both. There is a 60-per-minute ceiling scoped to each user and a 300-per-minute ceiling scoped to the Cloud project. A server-side app using one service account hits the per-user limit first, because every request is attributed to that single identity.

Can I raise the Google Sheets API quota?

You can request an increase to the per-project quota in the Google Cloud console, but it is slow and does not lift the per-user ceiling. Caching reads in front of the API is faster and removes the constraint entirely.

Does the Sheets API rate limit cost money to exceed?

No. Google does not bill for overage — it refuses the request with a 429. Standard use of the Sheets API is free, so the limit is a throughput ceiling rather than a billing one.

Sources

Related guides

Turn your sheet into an API in minutes

Paste a Google Sheet URL and get a live REST API and MCP server — no backend, no code, free to start.