Google started a pilot program on Tuesday, July 7, 2026, that lets developers waiting on Google Ads API Basic Access approval cut their review time from as long as five business days down to a matter of hours, provided they complete a brand verification step tied to their Google Cloud project. The mechanism, described in a post on the Google Ads Developer Blog, is optional for now. It works by asking developers to confirm their identity and application intent through an existing Google process, then feeding that verification status into the API access review pipeline.

Brand verification was not built for the Google Ads API. It originates in the OAuth App verification process, an identity-confirmation layer Google applies to any application requesting access to user data through its broader API ecosystem. What changed on July 7 is that Google Ads API review teams began treating a verified Google Cloud project as a signal for faster processing. According to Anash P. Oommen, writing on behalf of the Google Ads API Team, the change is designed to address demand that has outpaced review capacity. "We aim to reduce the review delays and better meet the significant interest from our developer community for Google Ads API access," Oommen wrote in the announcement.

What developers need to do

The process asks for two discrete actions, and Google's documentation is specific about the order in which they must happen. First, a developer must associate their Google Ads API developer token with a Google Cloud project. This step exists so Google's review systems know which project to check when brand verification status is queried; skip it, and there is no project for the reviewers to reference, regardless of how thoroughly that project has otherwise been verified elsewhere.

Associating the token carries no special conditions. Developers can use either the user authentication workflow or the service account workflow, and it makes no difference whether the underlying API call targets a test account or a production account. It does not even matter whether the call succeeds. Google's technical documentation states plainly that "it doesn't matter whether your API call succeeds or fails," a detail that lowers the bar for developers who might otherwise worry about generating a clean transaction before the token-project link registers.

Second, the developer completes brand verification for that Google Cloud project. If the same project has already been through brand verification for a different Google API in the past, the process does not need to be repeated. Developers managing several Google Cloud projects under one developer token only need to verify one of them.

The verification itself runs through the Google Cloud Console. A developer navigates to APIs and Services, then to the OAuth consent screen, and works through several configuration steps: filling in application details, switching the project's user type from Internal to External if it was originally scoped to a Workspace organization, setting the publishing status to "In production," and completing a branding section that captures details about the application. Once branding information is submitted, a Verify Branding button becomes active, and Google's systems run an automated check that the documentation says takes a few minutes. If errors surface, the interface displays them along with remediation steps. A successful check is followed by publishing the branding, at which point the project carries verified status.

One detail in the documentation is likely to catch out developers who assumed internal or testing-mode applications were exempt. Google's guidance elsewhere states that brand verification is not required for applications with an Internal user type or a Testing publishing status. For the purposes of Basic Access review specifically, that general guidance does not apply. The documentation is explicit: "for the purpose of reviewing the Basic Access application for the Google Ads API, this documentation supersedes any other guidance." Developers must switch their applications to External user type and In production publishing status if they want the verification signal to count toward a faster review.

How access levels work today

The pilot sits inside a four-tier developer token system that governs how much a given application can do with the Google Ads API. At the bottom, Test Account Access level, granted automatically once a developer completes initial API sign-up, permits 15,000 operations per day but restricts calls to test accounts only, meaning no real advertisements are served or affected.

Explorer Access sits above that. Google may upgrade a token from Test Account Access to Explorer automatically, without a separate application. Explorer allows a developer to reach production accounts - the accounts that serve live ads to real users - but caps daily operations against those accounts at 2,880, compared with the 15,000-operation ceiling that still applies to test accounts under the same tier. Explorer Access also blocks several categories of functionality outright, including account creation through the CustomerService.CreateCustomerClient method, user management functions, campaign planning services such as KeywordPlanService and ReachPlanService, and billing-related services including BillingSetupService and InvoiceService.

Basic Access level, the tier this pilot targets, permits up to 15,000 operations per day against both test and production accounts, without Explorer's functional restrictions. According to Google's documentation, Basic Access reviews typically take five business days under the standard process. The pilot does not change that stated turnaround for developers who skip brand verification; it offers a materially faster path for those who complete it. Once a Google Cloud project is confirmed as brand verified, according to Google, "your pending Basic Access application will be reviewed in the next few hours."

Standard Access level sits at the top of the ladder, permitting unlimited daily operations for most services, including GoogleAdsService.Search and GoogleAdsService.SearchStream. Standard Access requires an approved Basic Access token as a prerequisite and, according to Google's published guidance, typically takes ten business days to review. Brand verification, as described in the July 7 announcement, applies specifically to Basic Access applications and is not framed as a mechanism for accelerating Standard Access reviews.

Permissible use is a separate axis that applies only to Basic Access and Standard Access tokens, and it is not touched by the brand verification pilot. Google's documentation defines three permissible use categories: ad creation and management, which grants access to the full range of services needed to build and manage campaigns; reporting, restricted to GoogleAdsService.Search and GoogleAdsService.SearchStream, intended for developers who only need to pull statistics; and researching keywords and recommendations, which opens access to RecommendationService, KeywordPlanIdeaService, and KeywordPlanService for tools that generate campaign suggestions.

Why Google says this is happening now

The July 7 announcement does not appear in isolation. It follows a backlog Google publicly acknowledged in a separate Google Ads Developer Blog post on February 6, 2026, when the company disclosed that Basic Access and Standard Access application reviews were taking longer than the stated turnaround times. That February post, also authored by Oommen, attributed the delay to a jump in interest tied to several Google Ads API releases launched in close succession: the Explorer Access tier itself, an open-source Model Context Protocol server for the API released the previous October, and the Google Ads API Developer Assistant. Google said at the time that it had added reviewers to work through the backlog, without disclosing how many applications remained outstanding or how long the queue had grown.

Whether the July 7 brand verification pilot is a direct continuation of that February remediation effort, or a separate initiative that happens to touch the same review bottleneck, is not stated in either the Basic Access documentation or the developer blog post announcing the pilot. Google's July 7 post frames the change only in terms of reducing "review delays" and meeting "significant interest," language that echoes but does not explicitly reference the February disclosure. The Google Ads API Team has not published data quantifying how many pending applications exist at present or how the pilot's hours-long turnaround compares, on average, against the standard five-day figure across a representative sample of applications.

Google has been explicit that the pilot's future depends on data it has not yet collected. According to the announcement, the company "will closely monitor the developer experience throughout pilot surveys and use that data to determine the future changes to the application review process for developer token access levels." That framing signals brand verification could eventually shift from a voluntary accelerant to a more standard part of the review pipeline, though Google's current documentation keeps the practice optional. The Google Ads API Compliance team, according to the announcement, retains discretion to request that specific developers with pending Basic Access applications complete brand verification, even though the broader program remains a self-service option that developers choose to pursue or skip.

Developers who already hold an approved token, and who are not newly applying for Basic Access, do not need to complete brand verification at all under the current framing. This distinguishes the July 7 change from mandatory compliance shifts the API has undergone elsewhere. Google separately began requiring developer token holders to migrate Customer Match data uploads to the Data Manager API, with the older pathway ceasing to function entirely from April 1, 2026. Brand verification for Basic Access carries no equivalent firm cutoff; it remains a way to jump the queue rather than a requirement imposed on a deadline.

Context for a fast-moving API calendar

The brand verification pilot lands in a period during which Google has been shipping changes to the Ads API at an unusually high cadence. The company moved the API to a monthly release schedule starting in January 2026, a shift from the previous three-major-releases-per-year cadence, first announced in September 2025. Version 23 of the API, which introduced channel-level reporting for Performance Max campaigns, launched on January 28, 2026, according to Google's release documentation. Version 24 followed on April 22, 2026, adding a new cart data reporting resource and expanded lead generation conversion types. Minor updates v24.1 and v24.2 followed in May and June respectively, with v24.2 adding synthetic content labeling structures tied to the European Union's AI Act transparency requirements that take effect on August 2, 2026.

Each of those releases has, according to Google's own framing in the February backlog disclosure, contributed to rising demand for developer token access. The Google Ads API Developer Assistant, one of the three catalysts Google cited for the February backlog, reached version 2.0 on February 26, 2026, adding automated diagnostics for offline conversion tracking and full support for the then-new v23 release. The MCP server, the second cited catalyst, had been available in open-source, read-only form since October 7, 2025, letting AI applications query Google Ads campaign data through conversational interfaces rather than direct dashboard navigation.

The API has simultaneously been narrowing what developer tokens can do without migrating to newer infrastructure. Beyond the April 1 Customer Match cutoff, Google blocked new offline conversion imports through the Ads API from June 15, 2026 for any developer token that could not demonstrate prior use of the ConversionUploadService.UploadClickConversions method between December 2025 and May 2026. Tokens outside that allowlist now receive a CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE error on attempted uploads. That restriction, like the Customer Match cutoff before it, directs developers toward the Data Manager API, which Google formally launched on December 9, 2025 as a unified ingestion point across Google Ads, Display and Video 360, and Google Analytics.

Google has also been consolidating where developers go to find documentation and support across its advertising and measurement products. The company launched the Google Advertising and Measurement Developers Hub on April 6, 2026, grouping resources for the Ads API, the Display and Video 360 API, AdMob, Ad Manager, and various measurement tools under a single access point. That reorganization did not introduce new products; it consolidated existing documentation, community links, and multimedia resources that had previously been spread across separate domains.

Insight for the marketing technology community

The brand verification pilot matters most to a specific slice of the advertising ecosystem: agencies, marketing technology vendors, and independent developers who build tools that manage live Google Ads campaigns on behalf of clients, rather than the advertisers who use those tools day to day. A five-business-day wait for Basic Access approval can stall a product launch or delay a client onboarding by the better part of a week. Collapsing that into a same-day or next-day turnaround, for developers willing to complete an identity check they may need to do regardless for other Google API integrations, removes a scheduling variable that has affected the pace at which new advertising tools reach the market.

The February backlog disclosure, which PPC Land covered at the time, gave the first public signal that Google's own developer relations push - the MCP server, the Developer Assistant, and the Explorer tier - had generated more application volume than the review process could absorb on its stated timelines. The brand verification pilot reads as a structural response to that same pressure: rather than simply adding reviewers, as Google said it did in February, the company is now offering developers a way to pre-qualify for faster processing by completing a verification step that, for many organizations already working across multiple Google APIs, may already be complete.

For developers who have never gone through Google's OAuth App verification process for any other API, brand verification introduces a new administrative task, even if a modest one. The Google Cloud Console steps - configuring the OAuth consent screen, switching user type to External, setting publishing status to production, and completing branding details - are not deeply technical, but they do require access to a Google Cloud project with appropriate permissions, and they require developers to formally designate their application as intended for production use rather than internal testing, a distinction with implications beyond the Ads API review queue.

The optional nature of the pilot leaves an open question for the marketing technology sector: whether brand verification eventually becomes a prerequisite rather than an accelerant. Google's own language, committing to monitor "the developer experience throughout pilot surveys" before deciding on further changes, suggests the company has not settled on brand verification's permanent role in the review pipeline. Agencies and vendors evaluating whether to complete the process now, ahead of any possible future mandate, are weighing a modest one-time administrative cost against a currently optional, but potentially durable, advantage in review speed.

Timeline

  • October 7, 2025 - Google releases an open-source, read-only Model Context Protocol server for the Google Ads API.
  • December 9, 2025 - The Data Manager API formally launches with eleven integration partners.
  • January 28, 2026 - Google Ads API version 23 launches with channel-level reporting for Performance Max campaigns.
  • February 6, 2026 - Google discloses a developer token application backlog affecting Basic Access and Standard Access reviews, and introduces the Explorer Access tier.
  • February 26, 2026 - The Google Ads API Developer Assistant reaches version 2.0.
  • April 1, 2026 - Customer Match data uploads through the Google Ads API stop functioning; developers must migrate to the Data Manager API.
  • April 6, 2026 - Google launches the Google Advertising and Measurement Developers Hub, consolidating developer documentation.
  • April 22, 2026 - Google Ads API version 24 launches.
  • June 15, 2026 - New offline conversion imports via the Google Ads API are blocked for developer tokens without demonstrated prior use.
  • June 24, 2026 - Google Ads API version 24.2 launches with synthetic content labeling structures.
  • July 7, 2026 - Google launches a pilot allowing brand-verified Google Cloud projects to receive expedited Basic Access reviews within hours instead of the standard five business days.

Summary

Who: Google's Ads API Team, with the pilot announcement authored by Anash P. Oommen, targets developers, marketing technology vendors, and agencies holding or applying for Google Ads API developer tokens at the Basic Access level.

What: Google launched a pilot process letting developers complete brand verification for their Google Cloud project to receive expedited review of pending Basic Access applications, cutting typical review time from up to five business days to a few hours. The process requires associating a developer token with a Google Cloud project and completing an existing OAuth App verification step called brand verification.

When: The announcement was published on Tuesday, July 7, 2026, on the Google Ads Developer Blog. It follows a developer token application backlog Google disclosed on February 6, 2026.

Where: The pilot applies globally to Google Ads API developer tokens with pending Basic Access applications, administered through the Google Cloud Console and the API Center in the Google Ads web interface.

Why: Google states the change addresses review delays caused by increased developer interest in Google Ads API access, driven in part by recent releases including the Explorer Access tier, the Ads API MCP server, and the Ads API Developer Assistant. The company has framed the program as a pilot whose future depends on data gathered through developer surveys during the trial period.