Google Ads conversions in n8n: migrating to the Data Manager API before your pipeline stays broken

If an n8n pipeline pushing offline conversions to Google Ads started silently failing since mid-June, it's not an n8n bug: since June 15, 2026, Google shut down offline conversion import and enhanced conversions for leads on the classic Google Ads API, in favor of a separate API, the Data Manager API. It's the same underlying trend that has pushed ad platforms for years to consolidate their integrations around first-party matching data (hashed email and phone) rather than third-party cookies: a landmark study by Goldfarb and Tucker (Privacy Regulation and Online Advertising, Management Science, 2011 — see on Google Scholar) already showed that tighter advertising-tracking regulation could cut measured campaign effectiveness by more than 60% — which is exactly why advertisers benefit from securing a first-party matching channel that doesn't depend on cookies. This guide covers how to rebuild that pipeline in n8n with the Data Manager API.

What actually changed

Two flows used to be handled by ConversionUploadService on googleads.googleapis.com:

• Offline conversion import — a lead qualified in-store or closed in a CRM, reported back to Google Ads days after the ad click.
• Enhanced conversions for leads — a supplementary send of hashed email and phone to improve matching on a conversion already imported.

Both are now blocked on the classic Google Ads API and redirected to the Data Manager API, a single entry point Google designed to fan the same data out to multiple products (Google Ads, Display & Video 360, Google Analytics) without multiplying integrations. Enhanced conversions for web are still handled by the Google tag or Google Tag Manager on the browser side and aren't affected by this shift — only the server-side API flow changes.

Preparing the Google Ads account

Before touching n8n, two settings on the Google Ads side gate everything else:

1. Under Tools and settings → Conversions → Settings, accept the customer data terms if you haven't already — the API silently rejects events until this consent is checked.
2. Note the Google Ads customer ID (no dashes) of the account that should receive conversions: it's used as productAccountId in every call.

Enabling the Data Manager API and creating OAuth2 access

The Data Manager API lives in Google Cloud, not the Google Ads developer center:

1. In a Google Cloud project (existing or dedicated), enable the Data Manager API from the API library.
2. Create an OAuth 2.0 Client ID (Web application type) under APIs & Services → Credentials, with https://oauth.n8n.cloud/oauth2/callback as the redirect URI on n8n Cloud, or the equivalent URL for your self-hosted instance.
3. The scope required at authorization is https://www.googleapis.com/auth/datamanager — different from the scope n8n's native Google Ads node uses, so it needs its own credential even if it's the same Google account.

Setting up the credential in n8n

In n8n, create a generic OAuth2 API credential rather than the pre-configured "Google Ads OAuth2 API" credential, which doesn't carry the right scope. Fill in:

• Client ID and Client Secret from Google Cloud.
• Authorization URL: https://accounts.google.com/o/oauth2/v2/auth
• Access Token URL: https://oauth2.googleapis.com/token
• Scope: https://www.googleapis.com/auth/datamanager

Connect once to generate the refresh token, following the same logic covered in our Google OAuth2 setup guide. This credential then plugs into an HTTP Request node, authentication set to "Predefined Credential Type" pointing at the OAuth2 credential you just created.

Hashing user identifiers

The Data Manager API only accepts identifiers hashed with SHA-256, hex-encoded, on normalized values: lowercase, trimmed email, E.164-format phone (+33...). A Code node before the API call prepares these fields:

const crypto = require('crypto');

const normalizeEmail = (e) => e.trim().toLowerCase();
const hash = (v) => crypto.createHash('sha256').update(v).digest('hex');

return [{
  json: {
    ...$json,
    email_hash: hash(normalizeEmail($json.email)),
    phone_hash: hash($json.phone.replace(/[^0-9+]/g, '')),
  },
}];

The Crypto node's Hash operation (SHA256, HEX output) — see our Crypto node guide — runs the same calculation with no code, if you'd rather stick to standard nodes. Only hash email and phone: the transactionId (the lead or order ID on the CRM side) and the GCLID stay in plain text — they're technical identifiers, not personal data in the same sense.

Building and sending the event

An HTTP Request node, POST to https://datamanager.googleapis.com/v1/events:ingest, with the x-goog-user-project header set to the Google Cloud project ID, carries a body that identifies the destination and then the event:

{
  "destinations": [{
    "productDestinationId": "GOOGLE_ADS",
    "productAccountId": "1234567890"
  }],
  "events": [{
    "transactionId": "deal-48213",
    "eventTimestamp": "2026-08-13T09:15:00Z",
    "userData": {
      "userIdentifiers": [
        { "emailAddress": "{{ $json.email_hash }}" },
        { "phoneNumber": "{{ $json.phone_hash }}" }
      ]
    },
    "adIdentifiers": { "gclid": "{{ $json.gclid }}" },
    "conversionValue": { "value": "{{ $json.amount }}", "currencyCode": "EUR" }
  }]
}

This skeleton covers the common case of a lead qualified in a CRM several days after the click. The full request-body schema — optional consent fields, audience events distinct from events:ingest — is documented in Google's official events.ingest method reference; check there for any field not listed above before scaling up to a large volume, since the API schema for this recent product is still evolving quickly.

Avoiding duplicate sends

A CRM that fires the same status-change webhook twice would otherwise send the same conversion twice. The principle is identical to the one covered in our webhook idempotency article: check in a table (Supabase, or an n8n Data Table) whether the transactionId has already been sent before triggering the call, rather than relying solely on possible deduplication on Google's side.

Verifying and scaling up

Under Tools and settings → Conversions → Diagnostics, Google Ads shows the receipt status of events with a delay of a few hours. For an initial import of CRM history rather than a one-off flow, split the send into batches with a Loop Over Items node: the Data Manager API accepts multiple events in the same events array, but it's safer to stick to batches of a few hundred to isolate a partial failure easily rather than resending an entire file on error. If your workflow chains several calls in quick succession, handling 429 errors and retries follows the same logic covered in our guide on AI API rate limits, directly transposable to an ad platform API.

What doesn't change

If your n8n instance also calls the classic Google Ads API for other operations — pausing underperforming campaigns or generating Google Ads and Meta Ads reporting — those flows aren't affected by this shift: only conversion import changes its entry point. Both credentials (classic Google Ads OAuth2 for reporting, generic OAuth2 with the datamanager scope for conversions) coexist without conflict on the same instance.

Summary

Since June 15, 2026, offline conversion import and enhanced conversions for leads to Google Ads must go through the Data Manager API: a new endpoint (events:ingest), a new OAuth2 scope (datamanager), but the same n8n node pattern used for Meta's or LinkedIn's Conversions API — HTTP Request, SHA-256 hashing, deduplication by business identifier. If this pipeline already feeds an n8n-driven inbound lead qualification flow, the migration is limited to swapping one HTTP Request node for another, without touching the rest of the workflow. And if you need to keep an auditable trail of every conversion sent to an advertising third party — useful under a GDPR review of contact-data processing — the Supabase logging workflows in the Compliance & Audit Pack (€149) follow the same principle covered in our article on GDPR audit trails with Supabase, applied here to an advertising-conversion flow rather than internal personal data.