Google Ads API v20 Sunset: Upgrade Before June 10, 2026

If any reporting, bidding, or campaign-management workflow still calls Google Ads API v20, June 10, 2026 is a hard failure boundary. Any request sent to v20 after the cutoff will fail, so a healthy dashboard or successful scheduled job on June 9 does not prove that you are ready for June 10.

Your job is to find every remaining v20 request, move each affected workflow to a newer version, and produce evidence that the replacement works in production. That requires more than changing a version string. It requires an inventory, representative testing, a staged cutover, and monitoring that can distinguish fresh data from stale output.

Know exactly what will fail at the cutoff

The sunset applies at the API request boundary. It does not, by itself, mean that a Google Ads account or campaign disappears. It means a workflow loses access whenever the request it needs still targets v20.

The business consequence depends on what that request does:

• Reporting and data pipelines can stop collecting new data, leaving dashboards, attribution processes, or client reports with gaps.
• Campaign automation can stop reading or applying intended changes, including workflows connected to bidding and campaign management.
• Internal tools can fail when a user opens a screen, requests a report, or submits a change that depends on v20.
• Third-party platforms can break even when your own code is current, because the version choice may live inside the vendor’s backend.

A failed reporting job is not always visually obvious. A dashboard may continue showing its last successful dataset unless it also displays data freshness. A failed write does not necessarily leave an account in a safe or paused state; it may simply leave the previous campaign settings in place. Review each workflow’s retry, alerting, and failure behavior so that an API error cannot masquerade as a successful run.

Translate every technical dependency into an operational consequence. Instead of recording only “reporting service uses v20,” document which report stops, who consumes it, how quickly stale data becomes harmful, and who owns recovery. That mapping tells you which migrations must move first.

Key takeaways

• Google Ads API v20 requests will fail after June 10, 2026; the deadline is not a warning-only deprecation milestone.
• Inventory observed API traffic and stored configuration. Either view alone can miss a dependency.
• Test complete workflows on a newer API version, not merely authentication or one sample request.
• Run read-only comparisons in parallel where useful, but do not duplicate campaign-changing requests across versions.
• Cut over early enough to observe a full operating cycle and restore v20 temporarily if the new implementation fails before the sunset.

Build an inventory that includes hidden and dormant calls

Start with actual traffic, then reconcile it against code, configuration, schedules, and vendor dependencies. An application list assembled from memory will miss old scripts, shared services, and jobs owned by teams that no longer think of themselves as Google Ads API users.

Recent API activity in Google Cloud Console can help identify the methods and versions used by your projects. Review every relevant project rather than only the one associated with your main campaign application.

1. List the environments and projects. Include production, staging, reporting infrastructure, serverless jobs, shared integration projects, and systems managed by another team.
2. Inspect recent activity. Record which projects still produce v20 traffic and which methods they call.
3. Cover the complete job cadence. Your observation period must include infrequent workloads such as weekly, monthly, or manually triggered jobs. Zero traffic during an idle period proves nothing.
4. Search stored configuration. Look for literal v20 references, version selectors, client-library dependencies, deployment variables, request builders, infrastructure definitions, and copied scripts.
5. Attach an owner to every dependency. An unidentified service is not ready merely because it appears inactive. Someone must decide whether it should be migrated, retired, or verified as unused.

Traffic inspection and configuration inspection answer different questions. Traffic tells you what ran. Configuration tells you what may run later. Keep both in the migration register.

Ask vendors for feature-level confirmation

A generic claim that a platform “supports the Google Ads API” is not enough. One module may be current while a less visible exporter or automation feature still uses v20. Ask the provider:

• Which API version does each feature used by your account call in production?
• Has every v20 workload been migrated, or only the primary integration?
• When will the production cutover occur?
• How can you verify that your tenant is using the newer version?
• What happens to queued jobs, retries, and cached reports if a request fails?

Keep the response with your migration record, then test the feature yourself. Vendor confirmation transfers information, not operational responsibility.

Migrate the workflow, not just the version label

Choose a newer supported API version that works with your client stack and the capabilities your workflows need. Use Google’s release notes and upgrade guides to identify required changes. Do not assume that editing a version constant is sufficient: client dependencies, available fields, request structures, generated types, and response handling may also need attention.

A practical migration sequence looks like this:

1. Capture a baseline. Record representative inputs, expected outputs, normal completion signals, and current error behavior for each workflow. Use stable comparisons where possible because live campaign data can change during testing.
2. Update the client and application together. Change the supported client dependency, version configuration, request construction, and any code affected by the official upgrade guidance. Check deployment manifests and runtime variables as well as the repository.
3. Test authentication and simple reads. Confirm that the application can connect using the credentials and account scope it will use in production. Connectivity is only the first gate, not the completion criterion.
4. Exercise representative read workflows. Run the same account scope, date range, filters, pagination path, and downstream transformation used by the real job. Compare required fields, completeness, row-level invariants, and freshness rather than relying on a single successful response.
5. Test writes under controlled conditions. Do not change live spend merely to prove connectivity. Use an approved test environment, test account, or non-spend-altering path where your setup supports one. Verify that the intended resource changes once and that retries cannot duplicate an action.
6. Validate downstream consumers. A successful API response does not prove that a dashboard, warehouse load, bid process, notification, or internal interface can consume the new output correctly.
7. Release in stages. Move a bounded set of workloads first, watch their results, and expand only after the expected operating signals remain healthy.

Parallel validation is useful for read-only workloads. You can run equivalent reporting requests on v20 and the target version, then compare the resulting datasets while v20 remains available. Avoid sending campaign-changing requests through both versions: duplicate writes can produce real account changes and financial consequences. For write paths, use a controlled test followed by a staged production rollout.

Preserve a temporary rollback path during the early cutover, but recognize its expiration date. Before June 10, a rollback to v20 may buy time to fix a problem. After the sunset, v20 is no longer a viable recovery plan because its requests will fail. Your post-cutoff contingency must keep the newer version in place, disable the affected workflow safely if necessary, and route the failure to a named owner.

Define readiness with production evidence

“The code was upgraded” is a progress update. It is not a definition of done. Close the migration only when you have evidence across configuration, runtime traffic, workflow output, and ownership.

• Every known application, script, scheduled job, and integration has an owner and an explicit migrate-or-retire decision.
• Each active workflow completes successfully on the selected newer API version using representative accounts and request types.
• Production configuration and deployed client dependencies point to the intended version.
• No v20 activity appears across the relevant Cloud projects during a period that covers the full operating cadence of the workflows.
• Reporting outputs expose freshness and completeness, so stale data cannot look current.
• Campaign-changing automation has controlled retry behavior and a human receives actionable failure alerts.
• Third-party features have been confirmed by the provider and verified through your own account-level test.
• The rollback plan works before the cutoff, and the post-cutoff contingency does not depend on v20.
• Campaign owners, analysts, engineers, and support staff know when the cutover occurred and where failures will be reported.

Be careful with negative evidence. Seeing no v20 requests is meaningful only if every relevant workload had an opportunity to run. A monthly exporter that has not reached its schedule can remain invisible until after the deadline. Pair runtime inspection with the dependency register, then record the last successful target-version execution for every retained workflow.

Set your internal cutover early enough to run a complete operating cycle while v20 can still serve as a temporary fallback. Name the owner, start the inventory, and schedule the target-version validation now. The date that matters internally should be the day you can prove v20 is gone, not June 10 itself.

References

• Search Engine Land — Upgrade Google Ads API: Avoid Service Interruptions by June 10