ECAPI: the "Universal" Conversions API Standard, Tested

On September 10, 2026, Google called its Data Manager API “universal.” The word raised eyebrows for anyone running a server-side container with three, five, sometimes eight Conversions APIs stacked inside it: universal, really? Behind the announcement sits ECAPI, the IAB Tech Lab standard meant to replace your pile of proprietary Conversions APIs with a single event schema. The promise is three words long: write once, send everywhere. The reality, once you open Google’s mapping docs, is a single observation: three gaps that break copy-paste. This article tells you what ECAPI changes for you today, what it does not, and how to prepare your event layer without rebuilding everything.

The short version. ECAPI finally gives Conversions APIs a shared vocabulary. But “shared vocabulary” is not “shared plumbing.” No platform today accepts a raw ECAPI payload without adaptation. Do not rebuild integrations that work. Instead, align your internal event layer with the ECAPI taxonomy: that is what saves you time when adoption actually lands, probably in 2027.

ECAPI in 150 words: what the spec actually says

ECAPI is the Event Conversion API standard published by the IAB Tech Lab, version 1.0 finalized on May 3, 2026. It was co-authored by the very players who receive your conversions: Meta, Google, TikTok, Walmart, and Roku. The idea is simple. Instead of each platform imposing its own server event format, everyone agrees on one schema. An ECAPI event carries a few required fields, including data_set_id, timestamp, and event_type, and leans on a full-funnel taxonomy that covers the whole journey, from top of funnel down to the complete lead cycle, from generate_lead to close_convert_lead.

That is what makes the standard interesting for a practitioner: it is not limited to the e-commerce purchase. It models B2B leads, retail media, CTV. The open question is who actually accepts it. The answer: nobody, not yet, not as-is.

What Google announced on September 10, and what its docs say

The September 10 announcement frames the Data Manager API as “universal” because it is built on ECAPI. This is the first official adoption of the standard by a major receiver, and it matters: the Data Manager API is the forward path Google has been pushing since it froze the Measurement Protocol. If you missed that shift, our Measurement Protocol vs Data Manager API comparison lays it out, and our Google Ads Data Manager guide covers the product interface you should not confuse with the API. That same September 10 announcement also carried the Data Strength Uplift metric.

“Universal” sounds great. Except Google’s own mapping docs show, in black and white, that an ECAPI payload does not travel into the Data Manager API as-is. You have to transform it. And the transformations are not cosmetic.

The 3 gaps between ECAPI and the Data Manager API

Here are the three points where “write once, send everywhere” breaks the moment you move from theory to Google’s docs.

1. Deduplication uses a different field. ECAPI identifies an event by its id key. The Data Manager API deduplicates on transaction_id. This is not a detail: map id to id naively and Google deduplicates nothing, so your server-side conversions risk doubling the browser ones. You have to route your unique identifier into transaction_id.

2. Routing uses a different field. In ECAPI, an event’s destination lives in data_set_id. In the Data Manager API, it goes through a destinations object. The field the standard makes mandatory is therefore not the one that actually drives delivery on Google’s side. Another transformation to write.

3. GPP consent is not read. This is the heaviest gap, and I come back to it in detail below. ECAPI carries consent through the GPP string. The Data Manager API does not read it and requires its own Consent object. In Europe, relying on the only mechanism the standard provides means sending data without the consent signal Google expects.

Bonus, because it trips everyone up on the first test: the timestamp format. ECAPI and many legacy CAPIs think in Unix timestamps. The Data Manager API expects RFC 3339. Send a 1757462400 instead of a 2026-09-10T00:00:00Z, and the event is rejected.

Three gaps plus one format trap. Each is surmountable, none is “universal.” The standard hands you a vocabulary; the plumbing, you still wire by hand.

The deduplication key table, platform by platform

This is the real friction point when you try to “standardize.” Every platform deduplicates on its own field, and ECAPI proposes yet another. As long as you generate one unique identifier per event and know which field to route it into for each destination, you are fine. Here is the mapping to keep in front of you.

The operational lesson: generate one event identifier, once, as early as possible in your server layer, then propagate it to the right field for each destination. That is exactly what ECAPI encourages, even though the field names still do not converge. The number of receivers keeps growing: Microsoft Ads launched its CAPI in pilot, and ChatGPT Ads arrives with its own. The more destinations you have, the more a single, centralized identifier becomes vital.

Consent: the blind spot in Europe

This is the topic nobody covers, and the most dangerous one. ECAPI has a built-in consent model. It carries the GPP string through gpp_string and gpp_sid, and it defines an mmt_only flag: measurement only, no optimization or targeting. On paper it is clean, and it is even the only consent mechanism the standard defines.

The problem, as I flagged above: Google does not read that GPP string. The Data Manager API requires its own Consent object. In other words, follow the standard to the letter in Europe and lean on gpp_string, and your consent never reaches Google. And one point the standard states without ambiguity: ECAPI does not generate consent, it only transports it. Collection stays your responsibility, upstream.

Practically, in the EU, you must keep wiring your consent signal in the format each platform expects, without assuming the ECAPI field will do the job. On the Google side, Consent Mode v2 is still the reference, the regulatory shift is tracked in our Digital Omnibus piece, and the question of ECAPI’s event_ip_address field ties directly into IP address handling in Google Ads.

Should you rebuild your Conversions APIs in your sGTM?

Honest answer: most of the time, no. Here is the grid I apply.

Leave it alone if your current CAPI integrations work, land, and deduplicate correctly. ECAPI brings no universal endpoint that would replace your wiring. Breaking a working integration to “move to the standard” is a bad idea in 2026.

Align your internal layer, on the other hand, and do it now. This is where ECAPI helps without breaking anything: name your events by the ECAPI taxonomy, generate a unique event_id once and propagate it everywhere, and centralize the normalization and SHA-256 hashing of your customer identifiers. That work is reusable regardless of destination. On server-side hashing, our server-side Enhanced Conversions guide details the method.

Prioritize in three cases. First the B2B lead funnel, because the ECAPI taxonomy models the whole cycle, from generate_lead to close_convert_lead: see Enhanced Conversions for Leads in sGTM. Then CTV and retail media, which the standard covers natively. Finally any new platform you wire in: you may as well start on aligned naming.

ECAPI-ready checklist in 6 points for your sGTM container

If you want to prepare your server-side without rushing, here are the six boxes to tick. They build on the practices in our server-side GTM guide.

1. One unique event identifier, generated once on the server, propagated to each destination.
2. Event naming modeled on the ECAPI taxonomy, including the full lead cycle.
3. Centralized normalization and SHA-256 hashing of customer data, not repeated tag by tag.
4. A timestamp stored in a pivot format, converted to RFC 3339 or Unix depending on the destination.
5. A consent signal wired in the format each platform expects, never assumed to be carried by the GPP field alone.
6. A documented mapping table, dedup key and routing field for each receiver.

What is still unclear, and worth saying

Let’s be clear about the limits, because a lot of content oversells this topic. Today, no universal endpoint exists. Every platform keeps its endpoint, its minimum fields, its rules. Google is the first major receiver to claim ECAPI, and even it requires transformations. As of now, there is no sign Meta or TikTok expose an endpoint that swallows a raw ECAPI payload: until they publish one, do not assume it.

Serious adoption is expected more around 2027. The momentum is real, driven by a context that makes the topic concrete: Safari 27 blocking pixel endpoints by IP, the proliferation of CAPIs, and the ECAPI guidelines for data clean rooms whose IAB consultation closed on September 4, 2026. But between “the standard exists” and “I copy-paste my payload everywhere,” there is still a year of plumbing.

So the right move: treat ECAPI as an architecture target, not a button to press. Align your event layer now, keep your working integrations, and you will be ready the day the receivers actually are.