Meta and Google Helped Write ECAPI 1.0 Without Promising to Honor It

The IAB Tech Lab finalized ECAPI 1.0 on May 3, 2026, a server-to-server specification that defines 42 standard marketing events advertisers can send to any participating platform using one shared payload. Meta, Google, TikTok USA, Walmart, and Roku helped author it, but none have publicly committed to a date when their existing CAPI endpoints will accept ECAPI requests. The "ext" field embedded in the spec lets each platform keep its proprietary signal requirements outside the standard.

That last sentence is the whole story. The standard is real, the press release is real, the GitHub repo is real, and the part that would actually save advertisers integration work is still optional.

42 events, four required fields, one shared payload

Strip the marketing language out of the spec on GitHub and what you get is fairly clean. ECAPI defines 27 standard marketing events plus 15 additional ones covering full-funnel activity, all sent over HTTPS as JSON. The required fields are short: data_set_id, a Unix timestamp, event_type, and custom_event if applicable. User identifiers (email, phone, name, address, postal code) get SHA256-hashed before they leave the advertiser's server. Deduplication runs off data_set_id plus event_id, and the response codes are the boring HTTPS set: 200, 400, 401, 404, 429, 500.

If you have built a Meta CAPI integration, a Google Ads enhanced conversions setup, and a TikTok Events API endpoint in the last three years, this looks like the wire format you would have wanted from the start. According to October 2025 industry data cited by PPC Land, two-thirds of advertisers reported improved ROAS after CAPI implementation. The same coverage notes that 72% of publishers identified technical integration as the major barrier to adoption. So the demand for one shared payload is not theoretical. It is the line item every analytics engineer has been logging hours against since 2020.

Why the "ext" field is doing most of the work

The honest read on the spec is that it standardizes the easy parts and leaves the hard parts to platform-specific extensions.

Meta's CAPI cares deeply about fbc and fbp click identifiers, fbclid parameters from URL clicks, and external IDs that match its ATC graph. Google's enhanced conversions need gclid, gbraid, and wbraid to attribute spend to campaigns. TikTok wants ttclid. None of those live in the core ECAPI fields. They live in ext objects, which the spec describes as a flexible framework for platform-specific customization.

Translation: the 80% of integration code you currently maintain because Meta wants different identifiers than Google wants is exactly the code you will still maintain after ECAPI adoption. The wire format is shared. The platform-required signals are not. From what I have seen in agency build-outs, the wire format is maybe 20% of the actual integration cost. The rest is signal mapping, identity resolution, hashing pipelines, and dedup logic.

The Anthony Katsur quote in the IAB press release frames it carefully: "Open standards for Conversion API support innovation and interoperability across the digital advertising ecosystem." That is technically true. It is also the version of "open" where every contributor reserves the right to keep their proprietary moat in a labeled compartment.

Who showed up to write it, and who is conspicuously missing

The contributor list, per Martech.org's coverage, reads like an upper-funnel media roster: Meta, Google, Walmart, TikTok USA, Roku, NBCUniversal, Paramount, Publicis Sapient, Basis Technology, and Warner Brothers Discovery. The publishers and agencies make sense. The platforms are interesting because of who is not in that list.

Snap is not on it. Pinterest is not on it. LinkedIn is not on it. Microsoft Ads is not on it. Reddit is not on it. Amazon is not on it. X is not on it.

That does not mean none of them will adopt the spec. It means none of them spent the engineering hours co-authoring it. If you run paid search and paid social, the platforms not in the room cover roughly half of your CAPI integration surface area. I would not assume they show up in a hurry. Their proprietary CAPI endpoints are part of how they justify higher CPMs against Meta and Google. A shared payload makes it easier for advertisers to pull spend toward whichever platform performs, which is exactly what challenger platforms have a structural reason to slow-walk.

The privacy critique nobody at the table wanted

Check My Ads filed comments in March 2026 raising a different concern: ECAPI makes it easier to share hashed PII at scale across platforms, but it does not strengthen consent. Hashing is a technical control, not a legal one, and SHA256-hashed email is still considered personal data under GDPR. Standardizing the pipe does not standardize the legal basis flowing through it.

That tension is real. The advertisers I talk to genuinely want fewer integrations. The privacy advocates point out that the same standardization makes auditing what data crosses where harder, not easier, because every implementation looks the same on paper while differing in scope underneath. Both can be true.

The 30-day audit worth running anyway

I would not rip out a working Meta CAPI integration to chase a spec none of the major platforms have committed to honoring on a public timeline. But I would do this:

Map your current event taxonomy to ECAPI's 42 standard events this week. The audit is a few hours of analytics engineering work, and the output is a spreadsheet that tells you which of your current events would map cleanly to ECAPI Add-to-Cart, Purchase, Lead, and Subscribe, and which sit in custom_event territory. That work pays whether or not Meta accepts ECAPI requests in 2026. You end up with a cleaner taxonomy either way, and if any platform announces ECAPI acceptance, you have already done the gnarly part of the migration.

The other thing worth tracking: which platforms expand their ext objects in their public ECAPI documentation, and which platforms absorb more fields into the core. The ratio is the adoption signal. A platform whose ext object is 40 fields long has not really adopted the standard. They have wrapped their existing CAPI in an ECAPI envelope.

For context on how Meta has been using one-click integrations to pull more advertisers into its first-party signal pool, our coverage of Meta's One-Click CAPI launch gets at the same dynamic from a different angle: free integration tooling is rarely free of strategic intent.

When this becomes real

My prediction: by the end of Q3 2026, two of the contributing platforms will publish ECAPI acceptance dates and the rest will stay quiet. The ext fields on those two will be longer than the core spec. By Q1 2027, advertisers will be sending one ECAPI payload that gets translated into three platform-specific calls inside the SDK they install, and the integration savings will be real but smaller than the press releases promised.

AdExchanger's CAPI explainer made the point bluntly back when CAPIs first proliferated: every platform building its own conversion API was a way of pulling first-party signal into its own walled garden. The spec is the polite version of saying that game has gotten too expensive for everyone to keep playing. It does not mean the platforms have agreed to stop. It means they have agreed on a vocabulary for how they describe playing it.

That is more progress than the industry has made on signal portability in years. It is also less than the press releases would have you believe.

Notice Me Senpai Editorial