Google Ads API: Moving Offline Conversions and Customer Match to the Data Manager API

Two Google Ads API workflows that most CRM and CDP connectors depend on, uploading offline conversions and syncing Customer Match lists, are no longer open to new adopters. Google’s deprecations page records both restrictions, and the replacement for each is the Data Manager API. If your connector already had traffic during the qualifying windows, it keeps working for now. If you are building a new one, or inheriting one whose history you cannot confirm, the Data Manager API is the path.

Here is what the documents say, where the two APIs differ in ways that break assumptions, and how to cut over without losing data.

What was restricted, and when

Google’s Google Ads API deprecations page lists three relevant entries:

Customer Match, April 1, 2026. Developer tokens with no Customer Match requests between October 1, 2025 and March 31, 2026 are restricted. Calls to OfflineUserDataJobService or UserDataService fail with CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE.
Offline conversions, June 15, 2026. Developer tokens with no offline conversion upload requests between December 17, 2025 and June 15, 2026 are restricted. UploadClickConversions fails with the same error.
Session attributes and IP address, February 2, 2026. New adopters of session_attributes_encoded, session_attributes_key_value_pairs, or IP address in user identifiers on conversion imports are restricted unless allowlisted.

The enforcement is per developer token, and it is based on observed usage. That has a practical consequence: a token that was dormant during a window can lose access even though the code is unchanged. Before assuming you are safe, check your logs for requests inside those windows, and treat any seasonal job, such as a quarterly list refresh, as a risk.

A note on what stays: this is about ingestion. Reading conversion actions or reporting data through the Google Ads API is not part of the entries above.

What changes in the request

Google publishes field-mapping tables for both workflows. The conversion mapping from UploadClickConversionsRequest to IngestEventsRequest is mostly renaming:

Google Ads API	Data Manager API
`gclid`	`ad_identifiers.gclid`
`conversion_action`	`destination_references` plus the numeric conversion action ID as `product_destination_id`
`conversion_date_time`	`event_timestamp` (RFC 3339 in JSON)
`order_id`	`transaction_id`
`user_identifiers`	`user_data.user_identifiers`
`custom_variables`	`custom_variables`, keyed by variable name instead of resource name
`consent`	`consent` (`ad_user_data`, `ad_personalization`)

For Customer Match, the shape changes more. The three-step Google Ads flow of creating an OfflineUserDataJob, adding operations, and running the job collapses into direct calls: IngestAudienceMembers, RemoveAudienceMembers, and RemoveAllAudienceMembers. The customer ID moves into destinations.operating_account, the user list resource name becomes a numeric product_destination_id, and the job ID is replaced by a request_id returned on the response, which you use to pull diagnostics. Mobile IDs are consolidated into a single mobile_ids array, and contact data can be bundled with IP data in CompositeData for improved matching.

The differences that break assumptions

Fast-fail replaces partial failure

The Google Ads API lets you set partial_failure so valid rows succeed while bad rows are reported. The Data Manager API has no equivalent. Google’s documentation says that if any field of an IngestEventsRequest fails validation, the entire request is rejected, and the audience upgrade guide says the same for audience members. A single malformed email in a batch of 2,000 events now fails the other 1,999.

Design for it. Validate and normalize records before they enter a batch. Use validate_only, which exists in both APIs, on new data sources or after schema changes. When a batch fails, split it and retry the halves to isolate the bad record, then quarantine that record with its error rather than retrying forever.

New credentials, no developer token

The Data Manager API requires credentials with a different scope from the Google Ads API: https://www.googleapis.com/auth/datamanager. Google tells you to generate new credentials that include it, so plan for a fresh consent step for OAuth users, and service accounts need to be added to the destination account or a parent manager account. The documentation distinguishes the login account (who authenticates) from the operating account (where data lands), and says a developer token is not required.

Quotas are documented per Google Cloud project, so check how many of your jobs share one.

Limits

Google’s documented limits for the Data Manager API:

IngestEventsRequest: up to 2,000 events per request, 10 user identifiers per event, 10 destinations per request.
Audience member ingest and remove requests: up to 10,000 audience members per request.
Per Cloud project: the ingestion service allows 100,000 requests per day and 300 per minute; other services allow 50,000 per day and 300 per minute.

Exceeding a limit returns RESOURCE_EXHAUSTED with HTTP 429. Batch to the maximum rather than sending one conversion per call, and put a token bucket in front of the client sized below 300 per minute.

Adjustments go through the same call

In the Data Manager API, if a transaction_id matches an existing conversion for the same conversion action, the request is treated as an adjustment. Conversion values are replaced rather than added, user data is added only when the original lacked it, and other fields stay as they were. Store sales adjustments are not supported. This is useful for refunds and corrected order values, and it means your retry logic should reuse the original transaction_id. It also means a bug that reuses IDs across different orders will silently adjust the wrong conversion instead of creating a new one.

Cutover plan

Inventory ingestion paths. List every job that calls UploadClickConversions, OfflineUserDataJobService, or UserDataService, and its schedule. Find out whether each one has recent traffic.
Add the scope and access. Enable the API in the Cloud project, request the new scope, and grant the login account access to the operating account.
Build a translation layer, not a rewrite. Keep your internal conversion and audience-member models, and write mappers that emit IngestEventsRequest and IngestAudienceMembersRequest. The tables above are the specification.
Run in validate_only first, then live traffic on a low-volume conversion action or a test user list.
Reconcile. Check request_id diagnostics and compare counts in Google Ads against your source. Remember that conversion reporting has its own latency, so reconcile on a delay.
Retire the old path once a full cycle, including month-end jobs, has run clean.

Google’s Data Manager API release notes show the surface is still moving. Version 1.5 added a user list service and lowered an audience threshold from 1,000 to 100 members, version 1.7 added IP address ingestion for Customer Match, and version 1.8 added RemoveAllAudienceMembers and detailed FieldWarning messages during ingestion. Pin the client library version, and read the release notes before upgrading it, as you would for any API that ships monthly.

The first thing to do is check whether your developer token has real traffic inside the windows above. If it does, you have time but not unlimited time. If it does not, build on the Data Manager API from the start.