Google today notified developers that Customer Match data uploads through the Google Ads API will stop working from April 1, 2026. The change - communicated via direct email to affected developer token holders - mandates a migration to the Data Manager API for anyone managing Customer Match audience lists programmatically. Developers who have not uploaded Customer Match data from their developer token in the last 180 days are specifically flagged in the notification.

The deadline is firm. According to the announcement, "effective April 1, 2026, Customer Match data uploads using the Google Ads API with your developer token will fail." This affects any implementation that relies on OfflineUserDataJobService or UserDataService within the Google Ads API to push data to Customer Match lists. Non-Customer Match operations - such as campaign management, bidding, and reporting - will continue functioning through the existing Google Ads API without interruption.

What is actually changing

The core shift is architectural. The Data Manager API, which Google launched on December 9, 2025, provides what the company describes as a unified data ingestion layer across Google Ads, Google Analytics, and Display & Video 360. Until now, developers had a choice: they could manage Customer Match uploads either through the older Google Ads API pathway or the newer Data Manager API. From April 1, that choice disappears for the OfflineUserDataJobService and UserDataService routes.

According to the notification, the Data Manager API "provides a unified data ingestion API for sending data across all Google platforms, with enhanced security protocols compared to the Google Ads API." The notification also cites two specific exclusive features that are available only through the newer interface: confidential matching and encryption. These capabilities are unavailable in the Google Ads API pathway and represent part of Google's stated rationale for the migration.

The distinction matters technically. Developers who have made no Customer Match data uploads via those two services in the past 180 days will receive an error immediately upon attempting to push data after April 1. Those who have been actively uploading data before that date will face the same hard stop once the deadline passes.

Why Google is making this change

The move follows a pattern Google has pursued systematically since late 2024: consolidating specialized data operations - particularly those involving first-party customer data - into a dedicated API built for that workload. The Data Manager API launch in December 2025 was explicitly framed around this consolidation. According to Ginny Marvin, Ads Product Liaison at Google, the API was designed because "managing multiple APIs for different platforms is a big headache."

The architectural logic is straightforward. Customer Match operations involve bulk uploads of hashed customer data - email addresses, phone numbers, physical addresses - at potentially high volumes. The Data Manager API uses an asynchronous processing model, which handles high-volume data imports more efficiently than the Google Ads API's synchronous request-response pattern. Concentrating these operations in one place also allows Google to enforce consistent validation rules, consent verification, and data retention policies across all Customer Match implementations, rather than managing those requirements across a more general-purpose API.

This is not the first time Google has drawn a sharper line between its APIs. In January 2026, the company announced that the Google Ads API would stop accepting new implementations of session attributes and IP address data in conversion imports from February 2, 2026, again directing developers toward the Data Manager API. The Customer Match change follows the same logic: complex, data-heavy, privacy-sensitive operations belong in the infrastructure built for them.

Technical scope of the migration

For developers, the migration involves several concrete steps. The Data Manager API operates through both REST and gRPC protocols. Authentication requires OAuth 2.0 credentials with the datamanager scope, and Google Cloud projects serve as the foundation for access. The API limits each Google Cloud project to 100,000 requests per day and 300 requests per minute. Individual requests can contain up to 10,000 audience members, and each audience member can include up to 10 user identifiers.

The interface supports Customer Match using three primary data types: audience members matched via Customer Match, mobile device identifiers, and Publisher Advertiser Identity Reconciliation (PAIR) identifiers. Data formatting requirements carry over from existing Customer Match implementations. Email addresses, phone numbers, and physical addresses must be SHA-256 hashed before transmission. Phone numbers require E.164 formatting. Address data must combine given name, family name, postal code, and two-letter country code in lowercase without punctuation.

A destination-based routing model is new to the Data Manager API. Each request includes a destination object containing three account identifiers: the login account making the API call, an optional linked account accessed through product links, and the operating account that receives the data. This three-tier structure accommodates complex organisational setups, including agencies accessing client accounts and manager accounts uploading data to sub-accounts. Developers can also use a validate_only parameter to test request formatting, authentication, and permission structures without actually ingesting data - a useful safeguard during initial integration phases.

For the Customer Match migration specifically, Google's blog post and upgrade guide (referenced in the notification) provide detailed implementation instructions. Developers replacing OfflineUserDataJobService calls need to map their existing request structures to the Data Manager API's audience upload format. The shift also introduces the terms_of_service_acceptedfield, which must be explicitly set to confirm acceptance of Google's Customer Match terms at the API level.

The migration has compliance dimensions that go beyond a straightforward technical swap. The Data Manager API enforces consent requirements aligned with Digital Markets Act regulations. Request-level and user-level consent settings allow developers to specify whether users have granted permission for ad user data collection and ad personalization. This enforcement happens at the API layer rather than relying on client-side implementation - a meaningful shift for developers building tools that serve multiple advertisers across different regulatory environments.

The 540-day maximum membership duration for Customer Match lists, established by Google in February 2025 and effective from April 7, 2025, also applies within the Data Manager API framework. Any lists that exceed 540 days generate a RangeError.TOO_HIGH error when the membership_life_span field is set above that threshold. Developers migrating their implementations need to ensure their data management logic respects this constraint.

The notification specifically targets developer token holders who have not uploaded Customer Match data in the past 180 days. This suggests Google is flagging dormant implementations - tools or integrations that were built but are not currently active - and treating them as new implementations for the purpose of the April 1 deadline. Active implementations need to migrate before that date; inactive ones will simply fail if reactivated without migration.

What stays the same

The notification is explicit on this point: non-Customer Match operations in the Google Ads API are unaffected. Campaign creation, bidding strategy management, ad group configuration, reporting, and all other standard advertising functions continue as before. Developers should not interpret this change as a broader migration away from the Google Ads API. The two APIs serve different purposes, and Google is delineating those purposes more clearly over time.

The Google Ads API has moved to monthly releases starting January 2026, reflecting continued active development. The current supported versions include v20 through v23, with Google maintaining a maximum of four major versions simultaneously. The Data Manager API and the Google Ads API will coexist as complementary tools, not competing ones.

Industry context

The April 1 deadline arrives as Google continues expanding the Data Manager API's reach. The December 2025 launch included partnerships with eleven marketing technology providers: AdSwerve, Customerlabs, Data Hash, Fifty Five, Hightouch, Jellyfish, Lytics, Tealium, Treasure Data, and Zapier. Treasure Data reported an 80 percent reduction in engineering effort following their Data Manager API implementation, according to reporting by PPC Land at the time of the launch.

For agencies and marketing technology vendors managing Customer Match implementations across multiple client accounts, the migration has broader implications. Any client whose account was being served by a developer token that has not uploaded Customer Match data in 180 days will face immediate upload failures on April 1 unless that integration is migrated to the Data Manager API beforehand. The 180-day inactivity window means some legacy integrations - built for clients but rarely exercised - may be at risk without proactive review.

The change also arrives in the context of Google's broader first-party data strategy. In November 2025, Google Analytics refocused its user-provided data infrastructure on advertising conversions and Customer Match, moving away from session attribution. The tag gateway rollout in May 2025 provided first-party domain routing for conversion tracking. The Data Manager API sits at the centre of this infrastructure push. Customer Match - which lets advertisers match their CRM data against signed-in Google accounts for targeting across Search, Shopping, YouTube, and Discovery - is a key activation mechanism for that first-party data strategy.

The minimum audience size for Customer Match was also standardised at 100 active users across Search, Display, and YouTube in late 2024, making the feature accessible to smaller advertisers. More developers and smaller agencies may now be managing Customer Match integrations than in previous years, which makes awareness of the April 1 deadline especially important.

Google's notification included links to both a blog post and an upgrade guide, which provide the detailed migration steps developers need. The Google Ads API forum and technical support channels remain available for implementation questions. Google has not announced any grace period beyond April 1.

Timeline

Summary

Who: Google's Ads API Team, targeting developers and marketing technology providers who use developer tokens to upload data to Customer Match lists via the Google Ads API - particularly those who have not made such uploads in the last 180 days.

What: Customer Match data uploads through the Google Ads API - specifically via OfflineUserDataJobService and UserDataService - will stop functioning entirely. Developers must migrate these operations to the Data Manager API, which provides a unified data ingestion interface with enhanced security, confidential matching, and encryption features not available in the Google Ads API.

When: The change takes effect April 1, 2026. Google issued notification to affected developers today, March 4, 2026. The 180-day inactivity window referenced in the notification means some dormant integrations are already out of scope and will fail immediately on the deadline date if not migrated.

Where: The change applies globally to all Google Ads API developer tokens that have used OfflineUserDataJobService or UserDataService for Customer Match uploads. The Data Manager API replacement is available via REST and gRPC protocols through Google Cloud projects.

Why: Google is consolidating all Customer Match data management into the Data Manager API, which it says delivers better developer experience, enhanced security protocols, and exclusive capabilities including confidential matching and encryption. The change continues a broader strategy of separating high-volume, privacy-sensitive data operations into purpose-built infrastructure, distinct from the general-purpose Google Ads API.

Share this article
The link has been copied!