API Rate Limits

API Rate Limits are usage quotas enforced by the Google Ads API that cap the number of requests, operations, and data volume an application can consume within defined time windows. They prevent any single application from overloading the API infrastructure and ensure fair access across all developers and tools.

Key Takeaways

• Restrict the number of API requests, mutate operations, and data queries per time period
• Applied at the developer token level (across all accounts managed by the token)
• Different tiers exist: Basic access (test), Standard access (production), and higher tiers by request
• Exceeding limits returns RESOURCE_EXHAUSTED errors requiring retry logic
• Efficient GAQL queries and batched operations help stay within limits

What Are API Rate Limits

API Rate Limits define the boundaries of how much you can do with the Google Ads API within a given timeframe. These limits exist at multiple levels:

Limit Type	Scope	Typical Threshold
Requests per day	Developer token	Varies by access level
Requests per second	Developer token	Rate-limited per second
Mutate operations per request	Single API call	Up to 5,000 operations per batch
Page size	Search/SearchStream	10,000 rows per page
Concurrent requests	Developer token	Limited simultaneous connections

How It Works

Rate limits are enforced at the developer token level, meaning all accounts managed through the same token share the same quotas. When your application exceeds a limit:

1. The API returns a RESOURCE_EXHAUSTED error (HTTP 429 or gRPC equivalent)
2. Your application should implement exponential backoff (wait, retry with increasing delays)
3. After the rate window resets, normal operation resumes

Developer token access levels:

Level	Intended Use	Limits
Test account	Development and testing	Low limits, test accounts only
Basic access	Initial production deployment	Standard limits for moderate usage
Standard access	Production applications	Higher limits for established tools
Advanced access	High-volume platforms	Custom limits by application

Best practices for staying within limits:

• Batch operations — Group mutate calls into single requests (up to 5,000 operations per batch)
• Use SearchStream — Streams results instead of paginated Search, reducing total requests
• Efficient GAQL — Request only needed fields, apply server-side filters
• Cache data — Avoid re-fetching data that has not changed
• Respect retry headers — Use the Retry-After header value when rate-limited

Practical Example

A management platform serves 500 accounts. Daily operations:

Operation	Requests Needed	Optimization	Optimized Requests
Pull keyword performance (500 accounts)	500 (one per account)	Use SearchStream	500
Update bids (100K keywords)	100,000 (one per keyword)	Batch 5,000 per request	20
Pull search terms (500 accounts)	500	Use SearchStream	500
Create new ads (1,000 ads)	1,000 (one per ad)	Batch 5,000 per request	1
Total without batching	102,000 requests		1,021 requests

Batching reduces the daily request count by 99%. Without batching, the platform would exceed rate limits within the first hour. With proper batching, it completes all operations well within quotas.

When a rate limit error occurs:

• First retry: Wait 1 second
• Second retry: Wait 2 seconds
• Third retry: Wait 4 seconds
• After 5 retries: Log the failure and alert the operations team

Why It Matters

API Rate Limits are a hard constraint that every Google Ads API application must respect. Applications that ignore rate limits experience cascading failures, incomplete data syncs, and degraded user experiences. The difference between a well-architected application and a fragile one often comes down to how it handles rate limiting — proper batching, efficient GAQL queries, caching strategies, and graceful retry logic. For platforms managing hundreds of accounts, rate limit management is not an afterthought but a core architectural concern that influences database design, job scheduling, and infrastructure sizing.