Google's Conversion API Cutoff Reads Six Months of Your Token Logs
Google's Ads Developer Blog confirmed on May 15 that the Google Ads API will block new offline conversion imports starting June 15, 2026. The cutoff applies to any developer token that did not call ConversionUploadService.UploadClickConversions between December 2025 and May 2026. Tokens outside that six-month usage window now hit a CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE error and have to migrate to the Data Manager API immediately.
The six-month window is the actual story
The June 15 date is not the news. Anyone who read the December 9 release of the Data Manager API knew the Ads API path was on a clock. I wrote up the May 12 v1.6 release and said the offline conversion path looked next. It was next.
What is new is the allowlist mechanism. Google is not just deprecating an endpoint, it is freezing access to it based on a six-month log of who actually used it. If your developer token did not import an offline conversion between December 2025 and May 2026, the Ads Developer Blog post says you get the CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE error from June 15 onward.
That's a tenure check buried inside a deprecation notice. The deadline is the soft part. The retroactive eligibility log is the part that catches people.
Why Google built it like a tenure check
The Data Manager API moves audience and conversion ingestion into a separate Google Cloud project with its own OAuth scope (datamanager) and its own quota: 100,000 requests per day, 300 per minute. It is not a wrapper on top of the Ads API. It is a parallel ingestion path with a different auth model.
From what I've seen, the tenure check serves Google's Smart Bidding signal continuity more than it serves developer hygiene. If Google had simply deprecated the Ads API path and let any new token onto Data Manager, you would get a flood of new offline conversion uploaders shipping low-quality signal under generic conversion actions. The allowlist filters out experimental and abandoned integrations before they get to inject noise into the new pipeline. Elevarus framed this as a Smart Bidding event, not a dev ticket, which is closer to the truth than the developer-blog framing.
The pattern is consistent with two earlier cutoffs. Session attributes and IP-based enhanced conversions got blocked February 2, 2026. Customer Match uploads followed on April 1. Each cutoff narrowed the legacy Ads API path and pushed traffic to Data Manager. The June 15 offline conversion cutoff is the third turn of the same screw, and the third time the announcement gave roughly six weeks of notice.
Who actually gets locked out
A few specific situations get caught here, and most of them are not "lazy developer" stories.
First, agencies that built offline conversion uploads as a per-client toggle. If a client onboarded after May and the agency was waiting for their CRM data to clean up before flipping the import on, that client's developer token has no offline conversion history. New uploads will fail. The agency now has to migrate the entire stack to Data Manager before they can run any offline imports for that client.
Second, marketing SaaS vendors that ship an offline conversion connector but rely on individual customers to enable it. The vendor's developer token may show usage from active customers, but if the token-level allowlist is per-account (which Google has not fully clarified), every customer that didn't ship by May becomes a new adopter under the rule.
Third, B2B advertisers running long sales cycles. If your offline conversion is a closed-won opportunity that takes 90+ days, and your team had a quiet Q1, your import cadence may have skipped enough months that the allowlist treats you as inactive. The error message is the same.
Fourth, and this is the one I'd be most worried about: teams running shadow QA environments. If you maintain a separate developer token for staging that you only fire occasionally, that token is almost certainly out of the allowlist by now. Migration testing on a fresh Data Manager project is the only path.
A practitioner on the Google Ads API developer group reported a similar allowlist error around WBRAID conversions earlier this year, where the developer-token-level enforcement caught teams that had been working on integrations but hadn't formally shipped. Same enforcement style, different surface. The pattern is recognizable.
The migration is bigger than swapping endpoints
The new endpoint is the easy part. The Data Manager API uses OAuth 2.0 with the datamanager scope and does not require a developer token, which is a structural change agencies should not underestimate. Three things actually move:
1. Auth model. You stop maintaining a developer token for offline conversions and start maintaining a Google Cloud project with OAuth credentials or a service account. App verification by Google is required if you're using user credentials at scale, and verification takes weeks. Start that now, not after June 15.
2. Schema. Data Manager unifies events across Google Ads, Google Marketing Platform, and Analytics. If you were sending Ads-only conversion payloads, you now share a schema with the GA4 measurement protocol crowd, which means stricter field validation. Expect to spend a sprint fixing edge cases in your event mapper.
3. Rate posture. The Ads API offline conversion endpoint had per-customer quotas. Data Manager is per-Cloud-project: 100,000 requests per day, 300 per minute, batched up to 2,000 conversions per request. If you're a multi-client agency pushing offline conversions through one Cloud project, you can hit that quota faster than you'd expect, and you'll need to split across multiple projects or batch more aggressively.
The Search Engine Land coverage of the announcement makes the point that the cumulative effect is consolidation into Data Manager. That's right. What the coverage understates is how much of that consolidation pushes complexity onto Google Cloud rather than onto Google Ads. The work doesn't disappear, it just changes departments.
What I'd do this week if I were running the migration
If your dev token imported offline conversions in the last six months, you have time. Keep using the Ads API path while you build Data Manager in parallel. Run dual writes for a few weeks, compare counts in the conversion action UI, then cut over. The PPC Land summary confirms simultaneous uploads from website tags, Data Manager, and API connections have been allowed since April, so you can run both pipelines without double-counting if you tag your events.
If your dev token didn't import offline conversions in the last six months, you're already locked out for new uploads. The order I'd run is: get a new Google Cloud project provisioned and the Data Manager API enabled today. Submit for OAuth app verification this week if user credentials are part of the design. Build the event mapper against the unified Data Manager schema rather than translating from your Ads API payload format; that path has fewer rough edges. Stress-test the rate limits with one client before fanning out across the book.
The teams that get hurt by June 15 are not the ones who knew about the Data Manager API. They're the ones who saw the May 15 blog post, assumed they had time because they'd been working on offline conversions all year, and didn't realize their developer token had been quiet for the part of the year Google was actually logging.
One reading nobody is offering yet
Google has now done the same enforcement pattern three times: silently log usage of an Ads API surface for six months, then publish a deadline that grandfathers the active users and locks out everyone else. Session attributes, Customer Match, offline conversions. The Customer Match move was the test. The offline conversion move is the template.
The question worth thinking about is which surface gets this treatment next. Enhanced conversions for web, store sales uploads, and customer revenue value adjustments all live on the Ads API and all have Data Manager parallels in active development. If you build long-running integrations against any of those endpoints, the safe assumption seems to be that Google is already logging usage and will publish a six-month tenure-based allowlist when the Data Manager replacement reaches GA.
Probably not the headline anyone wanted from a developer-blog post that read like a routine deprecation notice. But that's what the pattern keeps saying, and it has stopped being subtle.
Notice Me Senpai Editorial
