google-adsapimigration

Google Ads API v22 shut down October 7, 2026: find every remaining caller now

Google Ads API v22 shut down October 7, 2026. Find failed or low-frequency callers, migrate them, and verify production is clear.

The short version

Google Ads API v22 shut down on October 7, 2026. Requests to v22 now fail.

Check Google Cloud usage and application logs for failed or attempted v22 calls, including low-frequency jobs and vendor integrations. Migrate every remaining caller to a supported version, exercise its real business workflow, and keep monitoring for at least one full run of every scheduled job.

Start with observed calls and failures

An inventory of known integrations is useful, but recent API usage and error logs are 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 or failure;
  • 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 recovery scripts can all retain an old version.

If a third party owns the integration, ask for the exact deployed API version and dated evidence of a successful supported-version call. “We support Google Ads” is not enough.

Triage production impact first

Prioritize any remaining v22 dependency that affects:

  1. conversion or offline-data uploads;
  2. bidding or budget automation;
  3. daily reporting and downstream data freshness;
  4. audience synchronization;
  5. account provisioning or operational support.

For each failure, preserve the request time, method, job or application identity, error response and downstream impact. Do not repeatedly retry v22: the version is shut down, so retries cannot restore service.

Choose the replacement deliberately

Move to a version that Google currently 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 while production is impaired.

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 the replacement version with the last trusted v22 baseline 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 recovery sequence:

  1. deploy the supported 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.

Do not keep v22 as a fallback. It is a permanent failure path after the shutdown.

Prove that v22 is gone

The migration is complete when:

  • no production application or scheduled job is configured for v22;
  • recent Google Cloud usage and error logs show no unexplained v22 attempts;
  • 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.

Observe long enough to cover each job’s real schedule. A weekly or monthly job will not appear during a one-day check. Keep a dated exception list for jobs that cannot yet be observed, with an owner and next run time.

If v22 failed before you migrated

Treat the problem as an incident, not a future migration project. Freeze unrelated changes, assign an owner, restore the highest-impact workflows first, and annotate every affected report or automation window.

After recovery, backfill missed reporting or uploads only where the destination supports it and the operation is safe to repeat. Check for duplicate conversions, duplicate writes and partial runs before replaying jobs.

Sources