TL;DR
- Call conversions use a new call_info field with start_timestamp, a SHA-256 hashed E.164 caller number, and a conversion action of type UPLOAD_CALLS.
- Every ErrorCount and WarningCount now carries record_indices: [0, 3] with CLICK_NOT_FOUND means the first and fourth events failed.
- Unlike the Google Ads API, the Data Manager API accepts duplicate call conversions and deduplicates later instead of returning CALL_CONVERSION_ALREADY_EXISTS.
- A new lead_id field carries the Google-generated lead-form ID, but Google says attribution using lead_id and match_id is not available yet.
Google added Google Ads call conversions to the Data Manager API on 4 November 2026, according to a post on the Google Ads Developer Blog by Lindsey Volta on behalf of the Data Manager API team. The same release adds a record_indices field to request diagnostics, so developers can see exactly which rows in an upload failed or triggered a warning, and a new lead_id identifier for lead-form conversions. Google says attribution using lead_id and match_id "isn't available yet".
What changed in the 4 November release
The Google Ads Developer Blog post describes three changes. Each one matters to a different group: call-heavy advertisers, anyone uploading offline conversions in bulk, and lead-form advertisers.
| Change | What Google says it does | Field or setting |
|---|---|---|
| Google Ads call conversions | Send call conversions to Google Ads through the Data Manager API | call_info with start_timestamp; hashed caller phone number in user_data |
| Row-level diagnostics | Lists the 0-based positions of records that had errors or warnings | record_indices on each ErrorCount and WarningCount |
| Lead IDs | Sends the Google-generated ID issued when a user submits a lead form | lead_id in ad_identifiers (attribution not available yet) |
Call conversions: how they are sent
Call conversions record when ads lead to phone calls and when those calls lead to customer actions that matter to the business. Until now, uploading the outcome of those calls was done through the Google Ads API. The Data Manager API now accepts them too.
Per the blog post, the event carries a new call_info field. Its start_timestamp holds the time the call started, and the caller is identified with a hashed phone number in user_data. Google's developer guide for sending call events fills in the details:
- The destination is a Google Ads conversion action of type UPLOAD_CALLS. In the Google Ads interface, Google says, that conversion action's source shows as "Call from Ads".
- The operating account is the Google Ads account that owns the conversion action, given as a 10-digit customer ID without hyphens.
- eventTimestamp is required and must not be earlier than callInfo.startTimestamp.
- userData is required and must include the caller's phone number, formatted in E.164, hashed with SHA-256 and encoded. Google's worked example uses a hex-encoded hash.
- conversionValue, currency, eventSource, customVariables and DMA consent fields are optional. The example sets eventSource to PHONE.
- Encryption is not supported for this use case, so the encryptionInfo field should not be set.
The guide also covers a data partner route: credentials from a data partner account can send call conversions for advertiser accounts that have a partner link, after Google approves the partner.
Workflow
Google's overview lists four steps: prepare destinations, prepare event data and identifiers (normalising and SHA-256 hashing contact details), build and send an events.ingest request, then check processing status and diagnostics with requestStatus.retrieve. Google recommends sending with validateOnly set to true first, to catch fast-fail errors before production data goes in.
Moving from the Google Ads API: what is different
The blog links to an "Upgrade call conversions from the Google Ads API" guide. That guide compares the two APIs for call conversions, and the differences matter for anyone with an existing integration.
| Topic | Data Manager API | Google Ads API |
|---|---|---|
| Caller phone number | SHA-256 hashed, in UserIdentifier.phone_number | Unhashed, in caller_id |
| Error model | Fast-fail | Partial failure |
| Duplicate call conversions | Accepted without an error; Google Ads deduplicates after processing | Rejected with CALL_CONVERSION_ALREADY_EXISTS |
| Data model | One model across Google Ads conversion use cases and Google advertising products | Google Ads only, different per use case |
Two of these rows change day-to-day behaviour. Phone numbers must now be hashed before they leave your system, so any pipeline that sends raw numbers needs a normalisation and hashing step. And duplicate handling flips: code that relied on a CALL_CONVERSION_ALREADY_EXISTS error to detect re-sends will no longer get that signal, because duplicates are accepted and deduplicated by Google Ads after processing.
The guide lists quotas and limits as project-based with per-request limits for both APIs. Neither the blog nor the upgrade guide gives a date for retiring call conversion uploads in the Google Ads API.
record_indices: finding the rows that failed
Google's blog makes a point many offline-import teams know well: a successful ingestion request does not guarantee that every record was processed. Before this release, diagnostics gave counts by reason. Now each ErrorCount and WarningCount includes record_indices, listing the 0-based positions of affected records in the original request.
Google's example: a record_indices value of [0, 3] on an ErrorCount with reason PROCESSING_ERROR_REASON_CLICK_NOT_FOUND means the first and fourth events in the request failed for that reason. Developers can use the index together with the reason to fix those records and resend them.
Warnings work differently. Google says records with warnings were not rejected, but some of their data was ignored, so the cause of the warning should be fixed in future requests. In practice a warning can mean a conversion counted with less information than was sent, which is easy to miss if only error counts are monitored.
For teams that log their upload batches, the practical change is simple: keep the order of records as sent, so an index from diagnostics can be mapped back to a CRM row, order ID or call record.
lead_id: a new identifier, with attribution still to come
The new lead_id field sits in ad_identifiers and carries the Google-generated ID issued when a user submits a lead form. Google says lead_id and the existing match_id field can be included as event identifiers for offline and multi-source events sent to Google Ads, Floodlight and Google Analytics destinations.
The limit is stated plainly in the post: attribution using lead_id and match_id is not available yet. Until it is, Google tells developers to include other identifiers so events are attributed. Sending lead_id alone today would not get a conversion attributed, based on what Google wrote.
What the source does not say
- No date for when lead_id and match_id attribution will become available.
- No date for any deprecation of call conversion uploads in the Google Ads API.
- No detail in the blog on how Google matches an uploaded call to an ad interaction. The guides describe the fields, not the matching logic.
- No country restrictions are mentioned for any of the three changes.
- No performance figures or match-rate data.
Who is affected
Advertisers who already upload call conversions through the Google Ads API are the most directly affected, because Google has published an upgrade path and the hashing and duplicate rules differ. Teams uploading any offline conversions through the Data Manager API gain the row-level diagnostics straight away, with no new setup beyond reading the new field. Lead-form advertisers can start sending lead_id, but should treat it as an extra identifier for now, not a replacement for the ones that drive attribution today.
Advertisers who track calls only through Google's own call reporting, without uploading call outcomes from their own systems, are not affected by the call conversion change.
What this means for Thai marketers
Many Thai lead-generation businesses, such as clinics, property developers, education providers and service firms, close sales on the phone. If a call from an ad becomes a booking or a sale, sending that outcome back to Google Ads gives Smart Bidding a better signal than the call alone. The Data Manager API now offers a route for that.
- Phone number formatting. The guide requires E.164 format before hashing. For Thai numbers that means the +66 country code and no leading zero. A mismatch in formatting before hashing means the hash will not match.
- Check diagnostics after every upload. With record_indices, failed rows can be traced to a specific booking or order. A recurring CLICK_NOT_FOUND reason is worth investigating rather than ignoring.
- Developer work is required. This is an API change. Businesses using a CRM connector or tag manager should ask whether their vendor plans to support Data Manager API call conversions.
- Do not rely on lead_id yet. Keep sending the identifiers that attribution uses today.
Relevant Audience's Google Ads management service covers conversion setup and bidding signals, and the Google Analytics 4 service covers measurement plumbing between your site, CRM and Google's tools.
A checklist for developers and account owners
- List every place call outcomes are uploaded today and through which API.
- Read Google's call conversion upgrade guide and confirm the hashing step for phone numbers.
- Review any logic that depended on CALL_CONVERSION_ALREADY_EXISTS errors.
- Test with validateOnly before sending production data.
- Store upload order so record_indices can be mapped back to source records.
- Monitor warnings as well as errors.
- Add lead_id where available, alongside the identifiers already in use.
Frequently asked questions
Can I send Google Ads call conversions through the Data Manager API?
Yes, Google added call conversion support to the Data Manager API in a release announced on 4 November 2026. Events use the new call_info field with start_timestamp and a SHA-256 hashed caller phone number, sent to a conversion action of type UPLOAD_CALLS.
What does record_indices show?
It shows the 0-based positions of the records in your original request that had a given error or warning. A value of [0, 3] on an error means the first and fourth records failed for that reason.
Does lead_id work for attribution now?
No, Google says attribution using lead_id and match_id is not available yet. Developers should keep sending other identifiers so conversions are attributed.
Do I have to move call conversion uploads off the Google Ads API?
The source does not say you must. Google has published an upgrade guide, but neither the blog post nor that guide gives a deadline or deprecation date for the Google Ads API route.
Is this available for Thai accounts?
The blog post and guides do not mention any country restrictions. The fields described apply to Google Ads accounts generally, but Google gives no country list.
Bottom line
The 4 November Data Manager API release moves call conversion uploads onto Google's newer data pipeline, adds row-level error and warning detail that offline-import teams have lacked, and introduces lead_id ahead of attribution support. The practical work is in hashing phone numbers, handling duplicates differently and reading diagnostics row by row. If you want help reviewing how offline and call conversions feed your Google Ads bidding, Relevant Audience can take a look.
