Google Ads API Integration Limits Relevant to Agentic Campaign Management

Most teams building automated campaign tools start by counting HTTP requests. The Google Ads API doesn't meter traffic by the call. It meters by the operation, and a single mutate request can carry up to 10,000 operations inside it. Each one of those operations counts on its own against the daily quota ceiling. A single request packed with 10,000 operations registers as 10,000 separate charges against the quota system.

The range of things that count as an operation is wider than most people expect going in. Search calls count. Every individual mutate operation inside a batch counts. All of it draws from the same daily pool, regardless of which service generated the call.

A sharper trap sits in how failures get counted. If Google rejects a request with a GoogleAdsFailure, you still lose the quota, even though nothing succeeded. The only calls that don't cost anything are the ones that never reach the service at all: a true network-level failure before Google's servers process it. Reject a mutate request for a validation error, and that's quota spent on nothing.

The four access tiers

The daily operation ceiling isn't something you buy. There's no pricing tier that unlocks more throughput. An access level, granted through an approval process, sets the ceiling, and since September 2026 that approval attaches to a Google Cloud project.

Four levels exist, arranged in a ladder. At the bottom sits Test, where you can't reach production accounts at all, only test accounts, capped at the daily operation ceiling. An agent that needs keyword research or audience sizing simply cannot get it done on Explorer access, no matter how clean the code is.

Basic access raises the ceiling to match Test's daily cap, but it opens up both production and test accounts. Brand verification is required before Basic gets granted.

Then there's Standard: unlimited daily operations against both test and production accounts. No ceiling. Back off the wrong one, and the throttle doesn't clear. That mismatch is a common source of retry storms, and it matters more once volume climbs toward the Standard tier this ladder is building toward.

Standard access requirements beyond volume

Standard access removes the daily ceiling entirely, so it can look like the finish line. It isn't one you can simply walk into by generating enough traffic. Earning Standard is sequential, manual, and explicitly gated on demonstrated volume, so a system that hasn't yet pushed close to the Basic ceiling gets turned down regardless of how well-built it is.

Five conditions have to be satisfied, in order. Basic access has to already be in place, because each level in the ladder is a prerequisite you cannot skip past. And volume has to already be there: if usage doesn't consistently approach the Basic daily ceiling, Google denies the application.

That last condition is the one that trips people up: Standard access is something you earn by first operating successfully, and at volume, inside a smaller box. The February 2026 backlog is a good illustration of how conditional this whole process stays even for qualified applicants. Being qualified didn't protect anyone from the delay.

An operator might try to spin up multiple Cloud projects and stack several Basic ceilings together to avoid going through Standard review. The September 2026 policy update closes that door. It explicitly prohibits any MCP server or proxy architecture that "solely replicates, wraps, or re-exposes Google Ads programmatic capabilities," and it requires agencies and advertisers to hold their own Google Cloud account and their own Google Ads access. If a system is multi-tenant, so it serves many advertiser accounts, Standard isn't optional. The moment a single Cloud project serves multiple advertisers, their operation ceilings aggregate together under that one project, and Basic's cap gets consumed fast.

The September 2026 governance shift

On September 9, 2026, Google moved where access control lives. Now it sits with the Google Cloud project. That's a structural change, not a cosmetic one, and it landed with retroactive force on applications that were already in flight.

Picture an integration running on September 8. A day later, that model wasn't the one Google recognized anymore. Now applications route through the Google Ads API Overview page inside Cloud Console. Any Basic application that had been submitted from the old API Center before September 9 was closed outright and had to be resubmitted fresh from the Cloud project's Overview page. Standard applications already submitted before that date got reviewed as usual, so the disruption landed asymmetrically, heavier on Basic applicants than on Standard ones already in the queue.

Brand verification shifted at the same time from an optional accelerator into a flat prerequisite for Basic access. The developer token itself hasn't disappeared. It's still present in requests for now, but it's optional, and a future major version will ignore it entirely, though Google hasn't named a specific version number or date for when that happens.

The practical upshot for anyone running an existing integration: approved access under the old model didn't carry forward automatically just because it had been approved once. Teams had to go back through the new Cloud Console path and resubmit. That reset is also what sets up the next problem, because the Cloud project is now the single point of continuity for access, and that continuity can be lost through simple inactivity.

The 90-day inactivity trap and surviving service-level limits

Reaching Standard access doesn't mean the constraints disappear. An inactivity clock and a set of per-service limits that Standard never touches keep operating underneath that unlimited daily ceiling.

The inactivity trap catches more teams off guard than almost anything else in this architecture. Three months of quiet is all it takes.

Below the daily ceiling, several service-specific limits keep operating no matter what tier a project holds. Keyword Planning services are capped at 1 request per second per customer ID for keyword ideas, historical metrics, and forecast metrics, with a slightly higher allowance of 2 requests per second per CID for ad group themes. Audience Insights has its own hard ceiling too, around 200 requests per day per customer ID for composition and targeting insights, and that becomes a real constraint if an agent does audience research across a large roster of accounts. Conversion upload is capped at 2,000 call or click conversions per request, shaping how offline conversion data has to be batched before it goes up. gRPC responses cap out at 64 MB per message, so large, field-rich reports have to be restructured or streamed in pieces.

Two more limits matter for specific workflows. Starting April 1, 2026, UserDataService and OfflineUserDataJobService for Customer Match became restricted for new adopters, and any new Customer Match integration now has to go through the Data Manager API instead. And the Billing and Account Budget service allows only one operation per mutate request, a tight constraint that forces budget changes to run sequentially rather than in batches, no matter how much daily quota an account is sitting on.

How rate limits create reporting failures in practice

Quota exhaustion rarely looks like an outage. That's what makes it dangerous. If you hit the ceiling mid-cycle, what comes back usually is a partial dataset that looks whole, and decisions get made on it as if it were complete.

Three failure patterns appear repeatedly in reporting pipelines built on this architecture. A budget pacing check or a ROAS review run against that report is working from a partial picture without any visible sign that anything's missing. The second pattern is unstable ETL jobs, where a bad retry loop turns a brief throttle into something much worse. Third is cross-platform KPI mismatch: if the Google Ads API stalls mid-refresh while another platform, LinkedIn for instance, keeps updating normally, a unified dashboard ends up blending numbers pulled at two different moments in time. That's a freshness problem rather than a math problem, but it still produces spend and conversion figures that don't match what shows up in the Ads UI itself.

The cooldowns that follow a throttle aren't short. Short-term limits trigger a 5-minute forced cooldown, long-term limits trigger 30 minutes, and either one is long enough to blow a reporting SLA that expects fresh numbers at a fixed hour. Retry strategy depends on correctly reading which kind of exhaustion just happened. The rate_scope field distinguishes an ACCOUNT-level throttle from a DEVELOPER-level one, so backing off the wrong scope leaves the real throttle untouched.

The multi-party approval requirement for write automation

Since the v24.2 release on June 24, 2026, a new layer sits on top of everything described so far. Some sensitive user-management operations, like user invitations and access level changes, can now need a second administrator to sign off before they take effect. This runs through a new beta feature called Multi-Party Authorization. Quota headroom and access level used to be the whole story for whether a write operation would go through. They no longer are.

MPA applies specifically to sensitive account operations, and write automation at any access tier now has to coexist with that gate wherever it applies. An agent holding Standard access, with plenty of quota left for the day, can submit a mutation on a protected operation and get back no immediate error. The operation can sit pending a human sign-off before it executes. Any downstream logic built on the assumption that "no error means done" breaks the moment it hits one of these gated operations.

This layer applies at both Basic and Standard tiers alike, in single-organization deployments and multi-tenant ones. Upgrading access level doesn't route around it. It has to be handled directly inside the system's own state management, treating "submitted" and "executed" as two separate states.

Access level as the safety envelope for read versus write agents

Everything up to this point collapses into one practical question: what access tier does a given piece of automation actually need, and that depends entirely on whether it reads or writes.

Read automation, things like pulling performance data, generating reports, running audience insights, or producing keyword forecasts, can operate comfortably within Explorer or Basic access and ship without ever going through Standard approval. The daily operation ceiling barely enters into it.

Write automation lives under a different set of rules. Write automation also has to handle the MPA gate on protected operations, and it carries the 90-day inactivity risk if the system goes quiet for a season.

Google's own products trace this boundary cleanly. It can run GAQL queries and list accounts, but it does not mutate anything. For any outside system aiming to run continuously across many advertiser accounts, covering research, building, launching, monitoring, and optimizing, the write path demands Standard access, MPA-aware state tracking, 90-day activity maintenance, and service-level throttle handling for every specialized service the system touches.

Designing around the limits: batching, pacing, and prioritization patterns that prevent quota collapse

None of this architecture is a wall to work around. It's a resource allocation problem, and the systems that keep running are the ones that treat quota as something to budget deliberately rather than something to bump against and hope for the best.

Batching is the clearest lever available. Backoff discipline closes the loop on throttling itself. And service-level scheduling keeps the per-service ceilings from being the thing that quietly breaks a workflow: routing keyword planning calls through a scheduler capped at 1 query per second per CID, and tracking audience insights calls against a daily budget per CID so the roughly 200-request ceiling doesn't get blown through before the end of the working day.

Each of these patterns ties back to a failure mode already on the table: retry storms, partial reporting data, stale dashboards, lost access after a quiet quarter. Designing around the limits means designing against those specific outcomes, not against an abstract notion of "running out of quota."

What continuous agentic campaign execution requires at scale

Calling a system "continuous" or "agentic" doesn't make it so. What makes it so is whether the system is built to sustain operation across the entire quota architecture at once: access approval, service-level limits, MPA governance, inactivity risk, and retry discipline, all simultaneously, not one at a time as problems surface.

The access tier ladder is slow by design, and it's conditional at every rung. A system meant to serve multiple advertisers at real scale has to plan for the Standard approval path, with its manual review, its Required Minimum Functionality compliance, its demo requirement, and its volume demonstration, well before it needs to operate without a daily ceiling, not after it's already hit one. The September 2026 shift to a Cloud project-scoped model changes who holds that relationship with Google: agencies and advertisers need their own Cloud accounts, proxy architectures that re-expose API capabilities are off the table, and every party inside a multi-tenant deployment needs its own standing in the approval hierarchy.

The MPA requirement on protected write operations formalizes something that sound agentic design would have required anyway. A human checkpoint on a consequential mutation is the correct governance model for decisions a business has to answer for, and the API now enforces that structurally as a built-in requirement.

That points toward a particular shape for how this work gets organized: a purpose-built agent environment handling the continuous execution, the batching, the pacing, the quota accounting, inside the architecture this piece has laid out, with a named human expert holding the judgment calls that now require MPA sign-off. It's the structure the API's own governance model is already pointing toward.