google-adsapimigration

Google Ads API v22 shuts down October 7, 2026: find every caller and migrate now

Google Ads API v22 stops working October 7, 2026. Inventory recent calls, migrate to a supported version, and prove production is clear before cutoff.

The short version

Google Ads API v22 shuts down on October 7, 2026. From that date, every request to v22 will fail.

Use Google Cloud Console to find recent v22 method calls, trace each caller to an owner, migrate it to a supported version, and verify that production traffic is clear of v22 before the cutoff. Do not treat a successful build or one upgraded application as proof that scheduled jobs, scripts and vendor integrations are safe.

Start with observed calls, not an application list

An inventory of known integrations is useful, but recent API usage is stronger evidence. Check the Google Cloud projects used for Google Ads API access and identify v22 calls by method and time.

For every caller, record:

  • Google Cloud project;
  • application, script or scheduled job;
  • owning team or vendor;
  • method and traffic volume;
  • production, staging or development environment;
  • authentication path;
  • last observed v22 request;
  • replacement version and migration status.

Look beyond the main campaign-management application. Reporting extracts, audience syncs, conversion uploads, budget automations, account-provisioning jobs, notebooks and dormant recovery scripts can all keep an old version alive.

If a third party owns the integration, ask for the exact deployed API version and a dated migration commitment. “We support Google Ads” is not enough.

Choose the replacement deliberately

Move to a version that Google still supports and that your client library can target. Check the version’s release notes and migration guidance before changing production.

Review the surfaces your integration actually uses:

  • resource and field names;
  • enum values;
  • request and response shapes;
  • mutate behavior and validation errors;
  • reporting queries;
  • client-library requirements;
  • authentication and Cloud-project configuration;
  • quotas, retry handling and partial-failure behavior.

Do not combine the version migration with unrelated feature work. A narrow change is easier to test, review and roll back before a fixed deadline.

Test the workflows that matter

A client that authenticates successfully has not proved the migration. Exercise the business operations the integration performs.

At minimum, test:

  1. account and campaign reads;
  2. every reporting query used by scheduled exports;
  3. creates and updates in a safe test scope;
  4. conversion or offline-data uploads where applicable;
  5. pagination, retries and partial failures;
  6. empty-result and permission-error paths;
  7. downstream tables, dashboards and alerts.

Compare representative outputs from v22 and the replacement version over the same closed period. Explain field, row-count or value differences before switching the production job.

For write workflows, verify the resulting Google Ads state—not only the HTTP response. Keep the changed resource IDs, request time and acceptance checks with the migration record.

Cut over with evidence

Use a controlled cutover:

  1. deploy the new version to a non-production environment;
  2. run a fixed acceptance set;
  3. compare outputs and resulting account state;
  4. deploy to production;
  5. monitor errors, latency, quotas and downstream freshness;
  6. inspect recent API usage again;
  7. remove v22 configuration and dead fallback paths.

Set an internal completion date before October 7. Leave time to find low-frequency jobs, resolve vendor delays and correct output differences.

Do not keep v22 as a silent fallback. A fallback that works during testing but remains configured will become a second failure path on the shutdown date.

Prove that v22 is gone

The migration is complete when:

  • no production application or scheduled job is configured for v22;
  • recent Google Cloud usage shows no unexplained v22 calls;
  • every required read, report and write workflow passes its acceptance test;
  • downstream data arrives on time and reconciles within the expected tolerance;
  • error alerts have an owner;
  • third-party dependencies have supplied version evidence;
  • obsolete v22 code and fallback configuration are removed.

Keep checking through the deadline. A weekly or monthly job may not appear during a short observation window, so compare the monitoring period with each job’s actual schedule.

What happens on October 7

This is a shutdown, not a gradual degradation notice. Google says all v22 requests will fail beginning October 7, 2026.

If v22 traffic remains close to the deadline, prioritize the workflows that affect bidding, budgets, conversions and daily reporting. Freeze unrelated changes, assign an incident owner, and preserve enough logs to identify every remaining caller quickly.

Sources