← All reports

September 28, 2026

What Breaks the Week Your Agency Leaves

Meta's v26.0 deprecations and Google's June 2026 upload changes turn a routine agency handover into a tracking outage. A 30-day fix.

Contents

What changed

Three platform changes landed between June and late July 2026. None were announced as agency-transition changes. All of them bite hardest in the week after an agency leaves, because that is the week nobody owns the plumbing.

Google moved conversion uploads out of the Google Ads API

Google Ads Help documents that offline conversion imports and enhanced conversions for leads uploads are migrated to the Data Manager API and blocked in the Google Ads API starting June 15, 2026. The same page sets a quieter condition: developer tokens that have not sent a request between January 2026 and June 2026 will not be allowlisted for legacy access. A dormant agency developer token is exactly the kind of asset nobody tests until it is needed. Google's Ads Developer Blog flagged the same shift in a May 15, 2026 post titled "Changes to Offline Click Conversion Import Support in the Google Ads API."

Two adjacent changes matter for the handover window. From April 2026, Google Ads accepts user-provided data simultaneously from website tags, Data Manager, and API connections. From June 2026, enhanced conversions for web and enhanced conversions for leads were combined into a single on/off feature, and the choice of implementation method was removed from that setting. During a transition you can now have three live sources writing user-provided data into one account, governed by one switch, with no obvious place in the interface that says which connection is actually doing the work.

Meta shipped a version boundary in the same window

Meta released Graph API and Marketing API v26.0 on July 29, 2026. Meta's version table lists v20.0 as expiring September 24, 2026. The v26.0 changelog deprecates a set of legacy Graph API protocol behaviors: the pretty and debug parameters are ignored, requests including date_format return an error, root requests of the form GET /?ids= return an error, and If-None-Match is ignored with the legacy ETag and 304 Not Modified behavior removed. Meta applies these to v26.0 and later from July 29, 2026, and to all remaining supported versions beginning October 27, 2026.

The same changelog deprecates the Commerce Order Management API, which Meta says covers 47 endpoints. Calls on v26.0 and later were blocked beginning July 29, 2026, the surfaces are removed from all remaining versions on October 27, 2026, and Meta states that no replacement API is available. Meta also maintains a separate index of out-of-cycle changes, which it defines as changes that impact all API versions at the time of their introduction. That index is the page most brands do not have on a calendar.

Meta changed who qualifies for Marketing API access

Meta's Dataset Quality API documentation, updated June 28, 2026, states that Marketing API tier labels were renamed: "Standard Access" is now Limited Access and "Advanced Access" is now Full Access. The qualification threshold for Full Access was reduced from 1,500 to 500 Marketing API calls in the past 15 days. Meta says existing access levels are preserved automatically and no code changes are needed. That is a lowered bar, which helps a brand bringing work in-house, and it is also a reason to check which tier the departing agency's app was actually operating under before you assume your own app inherits the same capability.

Why it matters at $50K+ per month

At this spend level the failure mode is not a dead account. It is a quietly degraded one. Meta's Conversions API documentation describes server events as linked to a dataset ID and processed alongside Meta Pixel, SDK, offline event set, and manual-upload events for measurement, reporting, and optimization. If the server side of that dataset stops, or starts duplicating, the account keeps spending while the signal it optimizes against changes underneath it. Nobody files a ticket, because nothing looks broken.

  • Deduplication depends on fields the agency controls. Meta's deduplication guidance describes matching browser and server events on the same event_id and event_name, with eventID passed as the fourth argument in the pixel's fbq track call. A second method matches on event_name plus fbp or external_id. Meta documents that under that second method a server event is not discarded if no browser event was received in the past 48 hours, and that when two events match, Meta generally prefers the event received first. If the outgoing agency's server container held the event_id generation logic, double-counting or silent dropping starts the day it is switched off.
  • Match quality is a visible score and it moves. Meta's Business Help Center describes event match quality as a score from 0 to 10, based on the customer information sent with server events and how well those events match to Meta accounts. It is the fastest read on whether a re-pointed Conversions API integration is still sending the same customer parameters it sent last month.
  • Pixel sharing has an order of operations that predates your handover. Meta's Ads Pixel Shared Accounts reference states that since the end of September 2024, POST /{pixel-id}/shared_accounts does not support sharing a pixel with an ad account when the business account does not have access to both, and directs developers to call POST /{pixel-id}/agencies or POST /{ad_account}/agencies first. Transitions that re-share assets in the wrong order fail with permission errors that look like platform bugs.
  • Tokens belong to somebody. Meta's documented paths for a partner sending server events run through a system user with Manage Pixel permission on specific pixels, or Facebook Login for Business, or the Meta Business Extension. Each of those is tied to the agency's app or business portfolio, not yours.
AssetUsually held byWhat breaks at handover
Meta dataset / pixelBrand or agency business portfolioAd account loses the dataset it optimizes against if sharing is removed before it is re-granted
Conversions API integrationAgency server container or middlewareServer events stop, or duplicate once a replacement starts, depending on event_id handling
System user access tokenAgency business portfolioServer event sending fails with OAuth errors
Google developer tokenAgencyConversion uploads blocked; legacy allowlisting depends on request history between January and June 2026
Offline conversion upload pathAgency scripts or middlewareOffline and lead conversions stop arriving, so bidding loses outcome data

What to do this month

Week 1: inventory ownership before anything is disconnected

Write down, per asset, the owning business and the identity that authenticates it. On Meta: the dataset ID, the business portfolio that owns it, which ad accounts it is shared to, which system user sends server events, and which app that system user belongs to. On Google: the developer token, the Data Manager connection, and the account that owns each conversion action. Confirm the brand's own business portfolio holds the pixel or dataset, then re-grant access in Meta's documented order rather than re-sharing directly. Do this while the agency still answers email. Ownership questions are cheap in week one and expensive in week four.

Weeks 2 and 3: prove deduplication on the re-pointed integration

Meta's own setup flow for the Conversions API ends with a verification step that confirms events are received, deduplicated, and matched correctly. Treat that as the acceptance test for the transition, not a formality. Send browser and server events for the same conversions, confirm that event_id and event_name agree across both, and watch event match quality against its pre-transition level rather than against any target number. If you run the old and new integrations in parallel during cutover, remember Meta's documented preference for the event received first: parallel running without shared event_id values is how brands end up reporting purchases twice and then cutting budget against inflated return figures.

Week 4: put both deprecation calendars in one place

Google publishes its Ads API sunset dates alongside its cadence rules: at most five major versions supported at once, roughly twelve months of life for a major version, no more than two required upgrades per year, and at least twenty weeks of overlap between a new version and the sunset of the oldest. Meta publishes a version table and a separate out-of-cycle changes index. A brand running its own integrations inherits the job of reading both. One shared calendar holding the dates that apply to your stack, including the October 27, 2026 all-version removals on Meta and your current Google Ads API version's sunset, is the deliverable. It takes an afternoon and it is the item in-house transitions skip most often.

What we'd watch next

October 27, 2026. Meta's v26.0 changelog applies both the legacy protocol deprecations and the Commerce Order Management removals to all remaining supported versions on that date. Pinning to an older version does not buy you past it.

The next Google Ads API sunset. Google's sunset table lists v22, released October 15, 2025, with a tentative October 2026 sunset, and gives v23 and v24 tentative sunsets of February 2027 and May 2027. Tentative is Google's word. Plan against the earliest date.

Numbers we could not verify. Several figures circulating in agency and vendor content this quarter did not appear in any primary source we were able to open, and we are flagging them rather than repeating them as fact: specific event match quality thresholds presented as pass/fail lines, percentage improvements in cost per event attributed to Conversions API upgrades, and dated claims about automatic Conversions API Gateway rollouts. Those are vendor and practitioner claims. If a pitch quotes one, ask for the measurement design before you act on it.

Sources