Google will change how its Ads API handles multi-party approvals starting the week of December 7, 2026, and has asked developers who use the security feature to update their code before that date. The changes, announced on November 4 on the Google Ads Developer Blog, hold back the creation of user access invitations until a second administrator approves them, add a dedicated error code for approval requests that have gone stale, and raise the number of pending reviews that can be resolved in a single API call from one to 100.

In Short

Google Ads makes a second administrator approve certain account changes, such as adding or removing a user, and software that manages Google Ads accounts has to follow the same rule. From the week of December 7, that software will not receive an invitation record until the second person says yes, it will get a clearer error when a request has gone out of date, and it can approve up to 100 requests at once instead of one at a time. If you build or run tools that add people to Google Ads accounts, the parts of the code that deal with invitations and approvals may behave differently after that date.

What Google published

The post, signed by Anash P. Oommen of the Google Ads API Team, appeared on Wednesday, November 4, 2026, under the labels authorization, google_ads_api and release. It is short. Three changes are listed, followed by a paragraph headed "Action required," and there are no figures on how many accounts, developers or approval requests are involved.

The opening paragraph supplies the context. "Earlier this year, the Google Ads API started requiring multi-party approvals (MPA) when performing sensitive API actions," according to the post. "Starting the week of December 7, 2026, we are introducing additional changes to improve the developer experience for multi-party approvals."

That framing matters. Nothing in the post changes which actions require a second approver, or who that approver can be. The changes concern how the API reports and processes approvals, not whether they happen.

The instruction itself is conditional. "If you use multi-party approvals, review and update your code to reflect the new API behavior before December 7, 2026," according to Google. Developers on version 26 are told to download the latest client library releases once v26.2 ships, to get support for the new error code. Technical support questions go to Google Ads API support, and discussion to Google's Advertising and Measurement Community server on Discord, according to the post.

How the approval requirement reached the API

Multi-party approval arrived in the API in late June. Version 24.2 of the Google Ads API, released on June 24, 2026, introduced a multi-party approval mechanism for sensitive account operations, covering user invitations and access level updates. A day later, Google published a separate developer post on the mechanics. According to that June 25 post, the rollout would start on July 27, 2026, and reach all users over the following weeks, with support added to every major version then live: v24.2, v23.3, v22.2 and v21.2.

Three operations trigger the check, according to the June post. One is inviting a user through CustomerUserAccessInvitationService.MutateCustomerUserAccessInvitation. The other two are updating or removing a user's access through CustomerUserAccessService.MutateCustomerUserAccess. When the API decides an approval is needed, it creates a MultiPartyAuthReview resource in a pending state, and the requested action waits.

Resolution happens through a separate service, MultiPartyAuthReviewService.ResolveMultiPartyAuthReview. According to Google, the approver must be another administrator, and it can be either a person or a service account with administrator privileges. Service accounts are non-human Google identities that call APIs with OAuth credentials instead of a person's login, which means an organization can, in principle, automate the second approval as long as the identity doing it holds admin rights. The requester can revoke a review while it is still pending. Pending reviews can be listed through a Google Ads Query Language search on the multi_party_auth_review resource, filtered to a pending status. Google's developer guide gives administrators 20 days to approve or reject a request before it expires.

The interface followed a similar path. On July 14, PPC Land reported that removing a user's access in Google Ads required a written justification and a second administrator's approval, with requests expiring after 20 days. That report was based on screenshots shared by users rather than an official announcement, and it noted that accounts with a single administrator appeared to have no way through.

Invitations will not exist until approval

The first change concerns what the invitation method returns. At present, according to the post, MutateCustomerUserAccessInvitation "creates the invitation and returns the resource_name of the invitation, but doesn't perform additional actions like sending an invitation email until the associated MPA request is approved."

In other words, an invitation object exists from the moment the call succeeds, even though nothing has been sent and the approval is still outstanding. From the week of December 7, that sequence changes. "If a multi-party approval is required, the CustomerUserAccessInvitationService.MutateCustomerUserAccessInvitation method will defer the creation of the access invitation resource until the multi-party approval request is approved," according to Google. "The resource_name field is not populated in such cases."

Once the review clears, "the access invitation resource is available from the review results," the post says.

The practical consequence is straightforward. An integration that stores the returned resource name - to track the invitation, cancel it later or show it in a dashboard - will receive an empty field whenever an approval is required. The invitation will only come into being after a second administrator has signed off, and its identifier will have to be read from the review rather than from the original call. Code that assumes the field is always filled, or that treats an empty value as a failure, would misread a pending approval as an error. The post does not name the field in the review results that carries the invitation, and gives no code example.

The change also removes an awkward middle state. Under the current behavior, an invitation exists while the approval governing it is undecided, and Google's June post noted that no new invitation can be created for that user until the review is resolved. Under the deferred model, a rejected or expired review should leave no invitation behind at all. That is an inference from the post's wording; the November 4 announcement does not discuss rejected, revoked or expired requests. Nor does it say what happens to invitations created under the current behavior whose reviews are still pending when the switch takes place.

A named error for stale requests

The second change gives developers a specific signal for a failure that previously had no name of its own. Google "will start returning a new MultiPartyAuthReviewError.STALE_MULTI_PARTY_AUTH_REQUEST error code in the partial failure field when a pending MPA request is no longer valid because the target resource was modified or deleted after the review was created," according to the post.

Consider the sequence the error is designed to catch. An administrator asks to remove a colleague's access, and the request waits for a second approver. Before anyone approves it, another admin changes that colleague's role, or the user is removed by other means. The original request now refers to a state that no longer exists. The new code marks that request as stale. The post does not specify which call returns the error, though its placement in the partial failure field points to a response to a write operation, such as an attempt to resolve the review.

Partial failure is a Google Ads API mode in which valid operations in a request go through and failed ones are reported individually, instead of the whole request being rejected. That detail connects to the third change, discussed below.

Version support is uneven. "This error code will be introduced in the upcoming v26.2 release," according to Google. "Older API versions (v23 through v25) will return a MultiPartyAuthReviewError.UNKNOWN error, and the unpublished_error_code field in GoogleAdsError.details will be set to MultiPartyAuthReviewError.STALE_MULTI_PARTY_AUTH_REQUEST."

So the same event will look different depending on the version an integration calls. On v26.2 and later client libraries, the error arrives with its own name. On v23, v24 and v25, the top-level code says only UNKNOWN, and the real reason sits in a secondary field inside the error details. An integration on an older version that checks only the main error code cannot tell a stale request apart from any other unknown failure. This mechanism lets older versions carry an error their published lists do not contain, at the cost of an extra lookup for anyone who wants to handle it.

From one review per call to 100

The third change is the simplest to state. "You can resolve up to 100 pending MPA reviews in a single call to the MultiPartyAuthReviewService.ResolveMultiPartyAuthReview method," according to the post. "Currently, this method is limited to one review per API call."

That is a hundredfold increase in what one request can do. By PPC Land's arithmetic, approving 100 pending reviews takes 100 separate calls today and will take one after the change. The organizations most likely to notice are those that process access changes in bulk: agencies onboarding a team across many client accounts, platforms provisioning users for advertisers, or an employer removing a departing staff member from dozens of accounts at once.

The batch limit does not change who approves. Each review still needs an administrator other than the requester, whether a person or a service account. What changes is the number of round trips. The post does not say whether the reviews in one batch must belong to the same Google Ads account, or whether a manager account can resolve reviews across its linked client accounts in a single request.

The batch change and the stale error fit together. In a batch of 100 reviews, some may refer to resources that have changed since the reviews were created. Reporting those through the partial failure field would allow the remaining reviews to be resolved while the stale ones are flagged individually. That reading is PPC Land's; the post presents the three changes separately and does not draw the connection.

Five weeks, a minor release and the holiday season

By PPC Land's count, 33 days separate the November 4 post from December 7. The June announcement gave a similar window: 32 days between the June 25 post and the July 27 start of the rollout.

The dedicated error code depends on a release that has not yet been dated. The post calls v26.2 "upcoming" without giving a date. When Google set out its release plan in October, it moved the Ads API to two releases a month starting with v26, and the tentative schedule placed v26.2 in November 2026 and v26.3 in December, with a warning that the December release might be skipped for the holidays. Version 26 itself shipped on October 14. If v26.2 lands in November as projected, the named error will be available in client libraries before the behavior changes take effect. Google has not confirmed that sequence.

The same schedule shows how long the older-version workaround will matter. Google projected sunsets for v23 in February 2027, v24 in May 2027 and v25 in August 2027. An integration that stays on v25 until its retirement would handle stale requests through the unpublished error code for roughly eight more months.

The timing also lands in the retail calendar. Thanksgiving falls on November 26 in 2026 and Cyber Monday on November 30, which puts the week of December 7 one week after the peak shopping weekend and in the run-up to Christmas.

What the post leaves out

Several points are not addressed in the announcement. It does not say which API versions receive the deferred invitation behavior or the higher batch limit. The stale error has an explicit version map; the other two changes do not. Both appear to be changes to how the service behaves rather than to the API's published structure, which would suggest they apply across versions, but the post does not say so.

The post also gives no data. There is no figure on how many approval requests the API has handled since July, how many go stale, or how many expire unanswered after 20 days.

There is one inconsistency in Google's own documentation. The advertiser-facing help page titled "About Multi-party approval for Google Ads" states that read-only roles and API users are exempt from the approval process. Two developer blog posts, from June and November, describe approval reviews created through the API and the code needed to handle them. The help page carries no visible date, and Google has not explained how the two statements fit together.

The same help page describes a fallback that the July reporting did not find. According to Google, if an account drops to a single administrator, multi-party approval is paused and pending requests are canceled, and approval resumes once more administrators are added. The help page also states that Google Ads support cannot approve, deny or bypass requests on an advertiser's behalf.

Why this matters for the marketing community

Multi-party approval is one layer in a broader tightening of account access at Google Ads during 2026, driven by account takeovers. In April, PPC Land reported that scammers posing as prospective clients were targeting Google Ads agencies, using a look-alike domain registered three days before the inquiry arrived in an attempt to exploit the account-linking process. A Google product liaison quoted in that report described phishing as a common method of gaining unauthorized access to accounts.

Other controls arrived in parallel. Since July 15, Google Ads has required a passkey for certain sensitive actions, including account linking updates and user access changes, a requirement Google announced to advertisers in May. Multi-party approval adds a second person to the same category of action. Together, the two measures mean that changing who has access to an account involves both a credential held on a device and, where approval applies, a second administrator.

Developers have faced their own tightening. Updated developer policies dated August 31 banned programmatic proxies from Ads API access, a definition covering hosted MCP servers and wrapper services that re-expose Google Ads capabilities, and required each integration to use its own Google Cloud project. On September 10, Google moved API access management to the Cloud Console and dropped developer tokens from access decisions, saying tokens would be rejected outright in a future major version.

Set against that sequence, the November 4 changes are refinements rather than new restrictions. They do not add a security requirement. They reduce the number of calls needed to clear approvals, replace a misleading intermediate state with a cleaner one and give developers a specific error where they previously had to guess. For agencies and software vendors that manage user access at scale, they cut the number of steps involved.

They still mean work, however. The deferred invitation behavior changes what a long-standing method returns, and integrations that read resource_name after creating an invitation will see different results from the week of December 7. The stale error requires different handling on v26 than on v23 through v25. And the 100-review batch limit, while optional to use, is only useful to tools that are rebuilt to take advantage of it.

For advertisers who do not write code, the visible effect depends on the tools they use. Access management platforms, agency dashboards and onboarding systems that sit on top of the API are where the changes land first. Whether those tools adapt before December 7 depends on their vendors.

Timeline

Summary

Who: The Google Ads API Team, in a post signed by Anash P. Oommen, affecting developers, agencies, access management vendors and advertisers whose tools invite, modify or remove users in Google Ads accounts through the API.

What: Three changes to multi-party approvals. Invitation resources will only be created after a second administrator approves the request, so resource_name comes back empty while approval is pending. A new STALE_MULTI_PARTY_AUTH_REQUEST error flags requests whose target changed or was deleted, arriving in v26.2 while v23 to v25 return UNKNOWN with the detail in a secondary field. And up to 100 pending reviews can be resolved in one call, up from one.

When: Announced on November 4, 2026. The changes start the week of December 7, 2026, and Google asks developers using multi-party approvals to update their code before that date. The error code depends on v26.2, which Google calls upcoming and its October schedule placed in November.

Where: Published on the Google Ads Developer Blog; the changes apply to the Google Ads API worldwide, specifically CustomerUserAccessInvitationService and MultiPartyAuthReviewService.

Why: Google describes the changes as improvements to the developer experience for a security requirement introduced to the API in mid-2026, part of a wider tightening of Google Ads account access that also brought passkeys and second-administrator approval in the interface.