Google Data Manager: the five upload pipelines it replaced

On this page

1. The API carries five upload jobs that used to be five integrations
2. Three doors have shut. Two of the five are still open
3. The grandfather rule is a closed window, not a rolling 180 days
4. The error blames your customer. The allowlist is on your developer token
5. It reaches six products, not just Google Ads
6. What to check this week, in order

Short answer: if your code uploads anything to Google Ads — customer lists, offline conversions, enhanced conversions for leads — the Data Manager API is where that work lives now, and three of the old entrances in the Google Ads API are already locked. They shut on 2 February, 1 April and 15 June 2026. Whether you can still use the old route turns on something most teams get wrong: not your Google Ads account, but whether your developer token made that kind of upload during a fixed window that has since closed. Miss the window and you get CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE, with no appeal except migrating.

One thing to settle first, because the names collide. "Data Manager" in the Google Ads interface is a connector UI for pulling data in from files and third-party sources. The Data Manager API is a separate thing: one HTTPS endpoint, datamanager.googleapis.com, that takes audiences and events for several Google advertising products at once. This post is about the API. If someone tells you they've "set up Data Manager" they may mean either.

The API carries five upload jobs that used to be five integrations

Google shipped it in pieces over sixteen months. From the release notes:

• Customer Match using contact information — v1.0, 2 April 2025. User ID as an identifier arrived in v1.5 on 17 February 2026, alongside a UserListService that creates and deletes the lists themselves.
• Mobile device ID audiences — v1.0, 2 April 2025, along with PAIR IDs.
• Offline conversion imports — v1.2, 6 August 2025.
• Enhanced conversions for leads — v1.2, the same release. In the Data Manager schema these two are the same call with a different event_source.
• Store sales conversions — v1.6, 7 May 2026, which added a store_id on the event and merchant fields on cart items. Google Ads account eligibility rules still apply on top.

That is the consolidation: five upload paths, one schema, one endpoint, one set of error codes. If you have built any two of these separately you already know why that is worth something — the old integrations disagreed about hashing, about batching, and about what a failure looks like.

Three doors have shut. Two of the five are still open

The Google Ads API's deprecations table is the authoritative list of cutoff dates, and it names three staged access restrictions. All three are now in the past:

All three throw the same error, and all three are described as restrictions on new adopters rather than shutdowns. Google's wording in the May 2026 announcement is that developers who had already adopted offline conversions "can continue importing using the Google Ads API while they integrate with the Data Manager API". So the old road is not gone. It is closed to new traffic.

Here is the part the summaries skip. Store sales and mobile device IDs are both supported by the Data Manager API, but neither has a matching restriction in the Google Ads API. The deprecations table has no store sales entry at all, and Google's own store sales help page still lists the Google Ads API as one of the ways to upload, next to the Google Ads interface, Data Manager and a store sales partner. As of 7 September 2026, the timetable covers three of the five workflows, not all five. Plan for the other two to follow — the direction of travel is not subtle — but do not tell a client that a date exists when it does not.

The grandfather rule is a closed window, not a rolling 180 days

This is where the received version of the story is wrong, and it is wrong in a way that costs money.

It gets described as an active-use rule: keep uploading and you stay grandfathered. It is not. Each restriction names a fixed lookback window with two hard ends, and the test is whether your developer token made a qualifying request inside it:

• Customer Match: tokens with no Customer Match requests between 1 October 2025 and 31 March 2026.
• Offline conversions: tokens with no offline conversion upload requests between 17 December 2025 and 15 June 2026 — a window of exactly 180 days, which is probably where the rolling-180 story came from.

Both windows are shut. Nothing you upload this month reopens them. A token that sat idle through the first half of 2026 is outside the allowlist permanently, and the remedy is migration rather than an appeal.

Worth knowing if you are checking your own dates: Google's two pages do not agree on the offline conversions window. The developer blog post of 15 May 2026 says "between December 2025 and May 2026"; the deprecations table, last updated 19 August 2026, says "between December 17, 2025 and June 15, 2026". The table is more precise and more recent, so it is the one to work from, but if you are close to the boundary, assume the tighter reading and check your own request logs rather than trusting either page.

The February 2026 restriction on session attributes and IP address had no lookback window published at all — only "developers who have already adopted".

The error blames your customer. The allowlist is on your developer token

CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE reads like an account problem. It is not. Both announcements say the same thing in the technical details: "Developers will be allowlisted by their developer token."

That inverts what people expect, in two directions:

A new advertiser account under an old token inherits access. Onboard a client tomorrow into a manager account whose token has been uploading offline conversions since 2024, and the upload works.

A new token gets nothing, however old the advertiser. Spin up a fresh developer token for a fifteen-year-old Google Ads account and every one of these calls fails. The account's history is irrelevant; the token has none.

For agencies and tool vendors running one token across many clients, that is the whole risk in a sentence: your token's history is a shared asset, and you cannot buy a replacement.

The February change has a quieter failure mode than the other two. Its error surfaces in the partial_failure response rather than failing the request, so a job can look successful while the conversions inside it are being dropped for carrying session attributes or an IP address. If you have not read your partial failures since February, read them before you conclude the migration is not urgent.

It reaches six products, not just Google Ads

The reason to treat this as an upgrade rather than a tax is the destination list. One IngestEvents or IngestAudienceMembers call can now address:

• Google Ads and Display & Video 360 — audiences, from v1.0.
• Google Analytics — purchase events from v1.4 in November 2025, then any non-reserved web or app event from v1.6 in May 2026, including Firebase app events. That is the same job GA4 Measurement Protocol does, with an upgrade path published for it.
• Campaign Manager 360, Search Ads 360 and Display & Video 360 offline conversions — v1.7, 28 May 2026, addressed through a FLOODLIGHT_CONFIG account type and a Floodlight activity ID.
• Google Ad Manager — audiences, per the API's own product list.

If you have ever kept a Floodlight uploader and a Google Ads uploader alive side by side, that consolidation is the payoff.

What to check this week, in order

1. Find your developer tokens. Every one your organisation uses, including the one inside a tool you bought. This is the unit the allowlist works on.
2. Query your request history against the two windows above. You are asking a yes/no question per token: did it make a Customer Match request between 1 October 2025 and 31 March 2026, and an offline conversion upload between 17 December 2025 and 15 June 2026?
3. Read your partial_failure responses. Conversions rejected for session attributes or IP address have been failing quietly since 2 February 2026.
4. Check what your vendor is doing, if a third party uploads on your behalf. Their token, their window, your data.
5. Then migrate. Google publishes upgrade guides per workflow, and the Customer Match help page now opens by recommending you avoid new Customer Match work in the Google Ads API entirely.

One thing this migration does not fix is the quality of what you are sending. Moving an upload from one endpoint to another does not improve the identifiers inside it, any more than moving your tags to a server does — a point worth reading alongside what server-side tagging actually recovers, because the same wishful thinking attaches to both.

The Data Manager API also changes how consent travels with an upload, and not in the direction you would hope: both consent fields are documented as optional, so an upload with no consent state attached is accepted without complaint. That is a separate problem with separate liability, and it is the subject of why Data Manager's optional consent fields are a problem.

If you want the migration scoped, the request logs read and the consent side checked at the same time, that is the kind of work we do.

Sources

1. 1.Google — Data Manager API overview · Checked 2026-09-07
2. 2.Google — Data Manager API release notes (v1.0 to v1.8) · Checked 2026-09-07
3. 3.Google Ads API — Feature deprecations and unversioned changes · Checked 2026-09-07
4. 4.Google Ads Developer Blog — Changes to Offline Click Conversion Import Support in the Google Ads API (15 May 2026) · Checked 2026-09-07
5. 5.Google Ads Developer Blog — Changes to Customer Match Support in the Google Ads API (4 March 2026) · Checked 2026-09-07
6. 6.Google Ads Developer Blog — Changes to IP Address and Session Attribute Support in the Google Ads API (7 January 2026) · Checked 2026-09-07
7. 7.Google — Data Manager API, Audiences overview · Checked 2026-09-07
8. 8.Google Ads Help — Store sales uploads: choosing your first-party data upload method · Checked 2026-09-07
9. 9.Google Ads Help — How to provide consent for Customer Match · Checked 2026-09-07