Offline conversions moved to the Data Manager API: a guide

If you send CRM outcomes back to Google Ads, such as qualified leads, signed contracts or phone sales, the plumbing changed this year. Google has moved offline conversion imports and enhanced conversions for leads from the Google Ads API to the Data Manager API. Existing integrations were given a grace period, new ones were not. This guide covers what happened, who is affected and how to migrate an upload job without losing conversions.

What changed, and when?

Three dates matter.

• Version 1.2 of the Data Manager API added support for sending offline conversions and enhanced conversions for leads to Google Ads through the IngestEvents method. The same release made an event source field required for these events, with values such as WEB, APP, IN_STORE, PHONE and OTHER.
• 15 June 2026. According to the Google Ads Developer Blog post on changes to offline click conversion import support, the Google Ads API stopped accepting new adopters of offline conversion imports from this date, including enhanced conversions for leads. Integrations that sent no offline conversion upload requests between 17 December 2025 and 15 June 2026 lost access, and their UploadClickConversions requests return CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE. Integrations that did upload in that window kept legacy access.
• 28 May 2026 (v1.7). The Data Manager API added offline conversions for Campaign Manager 360, Search Ads 360 and Display & Video 360, plus a conversion_count field on events. If you run conversions across Google Ads and Google Marketing Platform, one integration can now feed both.

The legacy allowlist was defined in terms of developer tokens. Developer tokens themselves were sunset on 9 September 2026 (see our article on the Google Ads API after developer tokens). Google has not, in the pages we checked, described how the offline conversion allowlist maps to Cloud projects after that change. Treat legacy access as temporary and plan the move now.

Who needs to migrate?

If you only use the built-in Google Ads Data Manager connections, this migration is not yours to run. Google lists Google Sheets, HubSpot and Salesforce among the supported data sources for offline conversions and Customer Match.

Why move rather than ride legacy access?

Google's upgrade guide lists concrete differences in favour of the Data Manager API:

• One data model. The same request shape covers all Google Ads conversion use cases, and since v1.7 also Google Marketing Platform. The Google Ads API used different models per use case.
• Session attributes and IP addresses. Available to every Data Manager API user. In the Google Ads API they were limited to specific users.
• Encryption. The Data Manager API supports encrypting user data in the request. The Google Ads API did not.
• No developer token. Authentication is OAuth with the https://www.googleapis.com/auth/datamanager scope.

How do the fields map?

Google publishes a field-by-field mapping from UploadClickConversionsRequest to IngestEventsRequest. These are the mappings that cause most bugs in practice:

The loss of partial failure is the change that bites hardest. A nightly job that used to upload 5,000 rows and log 12 failures will, unchanged, upload nothing when one row has a malformed timestamp. Validate before sending, and split large uploads into batches so one bad row costs you one batch rather than the night.

Tracking Whisper

What does a request look like?

The endpoint is POST https://datamanager.googleapis.com/v1/events:ingest. A request carries destinations, events, request-level consent, the encoding of user identifiers and an optional validateOnly flag. Each event needs at least one identifier: a click ID in adIdentifiers, session attributes, userData, or an IP address.

{
  "destinations": [
    {
      "operatingAccount": { "accountType": "GOOGLE_ADS", "accountId": "1234567890" },
      "loginAccount": { "accountType": "GOOGLE_ADS", "accountId": "9876543210" },
      "productDestinationId": "555123456"
    }
  ],
  "encoding": "HEX",
  "consent": {
    "adUserData": "CONSENT_GRANTED",
    "adPersonalization": "CONSENT_GRANTED"
  },
  "validateOnly": true,
  "events": [
    {
      "transactionId": "CRM-10482",
      "eventTimestamp": "2026-09-28T14:05:00+02:00",
      "eventSource": "WEB",
      "conversionValue": 1250.0,
      "currency": "EUR",
      "adIdentifiers": { "gclid": "EAIaIQobChMI-example" },
      "userData": {
        "userIdentifiers": [
          { "emailAddress": "223ebda6f6889b1494551ba902d9d381daf2f642bae055888e96343d53e9f9c4" }
        ]
      }
    }
  ]
}

Notes on this example:

• operatingAccount is the Google Ads account that owns the conversion action. loginAccount is the manager account you authenticate through, if any.
• productDestinationId is the numeric conversion action ID.
• Request-level consent applies to every event. You can set consent on an individual event instead, and event-level consent overrides the request level. Send the consent you actually collected: if a user denied ad_user_data, do not upload their hashed email as granted. Our Consent Mode v2 checklist covers how to carry consent state from the website into your CRM.
• Keep validateOnly set to true until the payload passes, then remove it.

Tracking Whisper

How should user data be normalised and hashed?

Google's formatting guide for the Data Manager API is specific. For email addresses: trim whitespace, lowercase, and for gmail.com and googlemail.com only, remove dots before the @ and drop a plus sign and everything after it in the local part. Phone numbers go to E.164 format, for example +18005550100. Hash with SHA-256 and encode as hex or Base64, matching the request's encoding value.

import hashlib

def normalise_email(raw: str) -> str:
    email = "".join(raw.split()).lower()
    local, _, domain = email.partition("@")
    if domain in ("gmail.com", "googlemail.com"):
        local = local.split("+", 1)[0].replace(".", "")
    return f"{local}@{domain}"

def hash_hex(value: str) -> str:
    return hashlib.sha256(value.encode("utf-8")).hexdigest()

print(hash_hex(normalise_email(" Cloudy.SanFrancisco+shopping@gmail.com ")))

Hash in the system that holds the raw data, not in a spreadsheet halfway through the pipeline. Mixed normalisation between two jobs is a common reason for match rates that fall after a migration.

What is the migration plan?

1. Inventory every upload path. Scripts, warehouse jobs, CRM workflows, call tracking and any vendor that posts conversions. Note which conversion actions each one feeds.
2. Set up OAuth for the Data Manager API. Enable the API in your Google Cloud project and request the datamanager scope. The user or service account must have access to the Google Ads account, directly or through a manager account.
3. Map fields using Google's table. Pay attention to the numeric productDestinationId, RFC 3339 timestamps and the request-level encoding.
4. Add pre-flight validation. Check timestamps, currency codes, non-negative values and at least one identifier per event before building the request, because one bad row fails the batch.
5. Run with validateOnly: true. Fix every error until the whole batch passes.
6. Run both paths in parallel for a short period, if you have legacy access. Send each conversion through only one path per conversion action to avoid double counting, for example by moving one low-volume action first.
7. Switch over and keep transactionId values identical. This keeps later adjustments and restatements consistent.
8. Check diagnostics. Store the requestId from each response and use it to retrieve request status, since there is no job_id any more.
9. Compare imported conversions in Google Ads against your CRM counts for the same dates for two to four weeks.
10. Retire the old upload code and document the new job, its Cloud project and its owner, so the next person knows where conversions come from.

Tracking Whisper

What about conversion adjustments and GA4?

Restatements and retractions also move. The Data Manager API documentation has a separate guide for conversion adjustments using IngestEvents. Plan them in the same project so your transactionId strategy covers both uploads and adjustments.

The Data Manager API is also growing beyond Google Ads. In 2026 Google added store sales for Google Ads and more event ingestion use cases for Google Analytics, and a Measurement Protocol upgrade guide sits in the same documentation. If you also send server-side events to GA4 through the Measurement Protocol, keep an eye on that path, but there is no migration deadline for it in the pages we reviewed.

Key takeaways

• Since 15 June 2026, new offline conversion and enhanced conversions for leads integrations cannot use the Google Ads API. Integrations without uploads between 17 December 2025 and 15 June 2026 receive CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE.
• The Data Manager API's events:ingest replaces UploadClickConversions, authenticates with the datamanager OAuth scope and needs no developer token.
• The biggest behavioural change is fast-fail validation: one invalid field rejects the whole request, so validate and batch.
• Map conversion_action to a numeric productDestinationId, use RFC 3339 timestamps and keep transactionId values unchanged.
• Built-in Google Ads Data Manager connections to Google Sheets, HubSpot and Salesforce need no API migration.

Offline conversions are a frequent blind spot in tracking checks because nothing on the website changes when an upload job fails. Tracking Whisper's monitoring watches conversion volumes in Google Ads and GA4 and alerts when they stop, which is often the first sign that a nightly import has broken. The Google Ads integration page describes what it reads.