Google Ads API Rate Limits Explained: How Quotas Work and How to Stay Under Them

If your script or integration just threw a RESOURCE_EXHAUSTED or "rate exceeded" error, the short version is this: Google Ads API limits are quotas on requests and operations, enforced at the developer token and account level. Most of the time the error comes from an inefficient request pattern, not from raw volume. A job that makes ten thousand tiny calls can trip a limit that a well-built job moving ten times the data never touches.

I can't verify live documentation from here, so this article explains how the limits work in concept and tells you where to confirm the exact figures. Google changes names, thresholds, and processes, and anything numeric belongs to the official docs, not to a blog post. Below: the kinds of limits, how to read the errors, what burns quota, how to stay under it, how to ask for more, and when you don't need the API at all.

The Types of Google Ads API Limits and Who Gets Hit

"Rate limit" gets used as a catch-all, but three different things can stop your requests. Knowing which one you hit decides the fix.

• Request rate limits. These throttle how fast you send requests over a short window. Exceed them and you get a temporary error. Slow down and the problem clears.
• Daily quotas tied to your developer token. A developer token is the credential that identifies your application to the API. Its access level determines how much work it can do per day. This is a quota, meaning a budget that resets on a schedule, not a speed limit.
• Per-request caps. A single call has its own ceilings, such as the maximum number of operations in one mutate request or the page size on a search response. These are not about frequency at all. They are about how big one request can be.

An operation is a single change inside a mutate request, such as creating one negative keyword or updating one bid. A mutate call changes data; search and searchStream on GoogleAdsService read it. Different request types are treated differently, which matters in the next section.

Access levels

Developer tokens come with an access level, historically Test, Explorer, Basic, and Standard, with each tier allowing more daily operations than the last. Test tokens work only against test accounts. As of October 2026, check the access-level table in the Google Ads API docs for the current tier names and daily allowances, because both have been revised before and I won't quote numbers from memory.

Who hits what

Consider an illustrative comparison. A freelancer runs one script against one account, pulling a search terms report and adding a few hundred negatives each week. They are unlikely to touch a daily quota, but a sloppy loop that fires a request per keyword can still trigger short-term throttling.

Now imagine an agency tool that loops through 50 client accounts every morning, all under one developer token. Every account's work draws on the same token-level budget, and if the jobs start at the same moment, the burst alone can trip rate limits. The freelancer has a pattern problem; the agency has a pattern problem plus a shared-budget problem.

Reading Rate Limit Errors Without Guessing

The API tells you more than most people read. Before changing any code, look at what came back.

You will typically see one of a few families of error. A rate-exceeded error (surfaced as RESOURCE_EXHAUSTED in gRPC terms, with a RateExceededError code inside the Google Ads error details) means you sent too much too fast. A temporarily-exhausted error means the service asked you to back off for a moment. A daily quota error means you used up your token's allowance for the day. Exact enum names and wording vary by API version and client library, so match them against the error reference for the version you run.

Finding which limit you hit

Don't stop at the top-level message. Log the full error payload. The error details usually include a message describing the limit, and for rate errors they include scope information, such as whether the limit applies to your developer token, a customer ID, or your Cloud project. Some responses also include a suggested retry delay.

That scope tells you where to act. A limit scoped to a single customer ID suggests you are hammering one account and should spread the work. A limit scoped to the developer token suggests the total across all your accounts is the issue, which is the agency scenario above.

What a rate error does not mean

A rate error is not a suspension, a policy strike, or a sign you did something forbidden. Short-term throttling is generally temporary: back off and the same request works. Daily quota exhaustion clears when the quota window resets. Check the docs for the current reset timing and time zone rather than assuming midnight in your own.

If you are seeing authentication, permission, or account-status errors instead, that is a different problem entirely, and retrying will not help.

Why Scripts and Tools Burn Through Quota

Almost every quota problem traces back to the same handful of habits.

• One request per item. Sending a separate mutate call for each keyword or negative when one call can carry many operations.
• Repeated polling. Re-running the same report every few minutes to see whether anything changed.
• Over-fetching. Pulling the full search term history with every column when you only need last week's new terms and four fields.
• Instant retry loops. Catching a rate error and immediately sending the request again, which just keeps you throttled longer.

Reads and writes are not the same

Reporting calls (search and searchStream) and mutate calls do different jobs and are limited differently. Reads can be heavy on data but light on account changes; mutates are the ones that count as operations against access-level allowances. Check the current docs for exactly how each is metered for your access level, because a script can be fine on one and strained on the other. A report-heavy tool and a bulk-editing tool fail in different ways.

An illustrative example

Suppose a script needs to review 10,000 search terms and flag the ones with spend and no conversions. The slow version loops through each term and asks the API about it individually: 10,000 requests, each one a chance to get throttled, and a lot of wasted overhead.

The efficient version sends a single query to GoogleAdsService, filtered by date range and metrics, selecting only the fields it needs, and streams back just the rows that match. One request does the work of thousands. The same logic applies on the write side: if that script then adds 800 negative keywords, it should send them in batched mutate requests, not 800 separate ones.

How to Stay Under the Limits: Batching, Backoff, and Caching

These fixes work in roughly this order of payoff. Most teams never need to get past the third.

1. Batch your mutates. Put many operations into one request, up to the per-request operation cap listed in the current docs. Fewer, fuller requests use far less of your rate budget than many small ones.
2. Use searchStream for large reports. It returns results as a stream instead of paging through them, which cuts the number of round trips for big pulls. Confirm its current behavior and any caveats in the GoogleAdsService docs.
3. Request only what you need. Select specific fields, filter by date range and status in the query itself, and skip entities that haven't changed. Less data per call, and fewer calls overall.
4. Add exponential backoff with jitter. When you hit a retryable error, wait, then retry with a longer wait each time, plus a small random offset. The randomness stops many workers from retrying in lockstep. If the error response suggests a retry delay, honor it.
5. Cache reference data. Campaign IDs, ad group IDs, and account hierarchies change slowly. Store them and refresh on a schedule instead of re-querying them on every run.
6. Spread the load. Run heavy jobs off-peak, and for agencies, stagger accounts across the window rather than starting all 50 at once.

On backoff: the official client libraries include some built-in retry behavior, but what is retried, how many times, and with what delays differs by language. Read your library's documentation before layering your own retry logic on top, or you can end up with nested retries that multiply traffic when things are already going wrong.

One more habit worth adopting: log request counts per job. When a quota error shows up, a simple tally of requests by type and customer ID usually points straight at the culprit.

Getting a Higher Access Level or More Quota

If you have tightened your request patterns and still need more headroom, the route is a higher access level, not a workaround. Access is managed through the API Center in a Google Ads manager account, where you can see your developer token's current level and apply for a different one.

Expect Google to ask about your use case. Applications for higher access have historically involved a description of the tool and how it uses the API, sometimes supported by design documentation, and Google reviews them against its terms and policies. Review timelines vary, so plan ahead and don't schedule a launch around an approval you don't have yet. Confirm the current form, required materials, and timelines on the official access-level page, as these details change.

A few practical points:

• Efficiency comes first. A request for more quota from a tool that makes thousands of avoidable calls is a weak case, and fixing the pattern may remove the need entirely.
• Tie the request to a real use case. More capacity is granted for a legitimate, documented application, such as managing your own accounts or building a tool for clients, not for headroom's sake.
• Don't quote thresholds from old posts. As of October 2026, the daily operation allowances and eligibility rules should be read from Google's current documentation, and may differ from what older forum threads describe.

Start at the Google Ads API documentation on developer token access levels (developers.google.com/google-ads/api) and read it with the current date in mind.

When You Don't Need the API for Search Term Cleanup

A lot of people land on API documentation because they want to do something simple at scale: go through the search terms report, drop the junk, add negatives, and promote the good queries to keywords. That is routine optimization work, and wiring up a developer token, OAuth, and a retry strategy just to do it is often more engineering than the task deserves.

For that kind of work, a tool that lives in the interface can be the easier path. Keywordme is a Chrome extension that works inside the Search Terms Report in Google Ads. You can add negative keywords, apply match types, and add keywords from the report itself, with no spreadsheet exports and no developer token or API quota for you to manage. You review the terms and make the calls; it just shortens the clicks.

To be clear about what that means: Keywordme is a browser extension for the Google Ads interface, not an API client, and nothing here suggests it gets around Google's limits or has Google's endorsement. It speeds up the work you would otherwise do by hand.

Where the API is still the right tool

The API earns its complexity when you need to:

• automate recurring jobs across many accounts on a schedule,
• build custom reporting or pipe data into a warehouse or dashboard,
• build a product or internal system that other people use.

If your goal is faster day-to-day search term pruning and keyword building, the API is usually overkill. If your goal is infrastructure, it is the right foundation, and everything in the earlier sections applies.

Google Ads API Rate Limits FAQ

Do rate limits apply to test accounts? Test accounts are used with test-level developer tokens, and they have their own restrictions and are not meant for live data. Check the current docs for how limits apply to test access.

Is the limit per account or per developer token? Both can matter. Some limits are scoped to the developer token, others to a customer ID or project, and the error details tell you which. See the section on reading errors above for how to find the scope.

Can I just retry? Yes for temporary throttling, but with exponential backoff and jitter, not an instant loop. A daily quota error will not clear by retrying, since you have to wait for the reset or reduce your usage.

Does the Google Ads interface have these limits? API quotas govern API requests. Using the Google Ads interface, including with a browser extension, does not involve your developer token. The interface may have its own limits on things like bulk actions, so check Google's help documentation for those.

Fix the Request Pattern First, Then Decide If You Need the API

Most rate limit problems get solved by batching mutates, writing tighter queries, and backing off properly on retryable errors, not by asking Google for more quota. Read the error details, find the scope, and cut the number of calls before you touch your access level.

And if what you really wanted was faster search term cleanup, you may not need to build anything. Optimize Google Ads Campaigns 10X Faster. Without Leaving Your Account. Keywordme lets you remove junk search terms, build high-intent keyword lists, and apply match types instantly, right inside Google Ads. No spreadsheets, no switching tabs, just quick, seamless optimization. Start your free 7-day trial (then just $12/month) and take your Google Ads game to the next level.