ECAPI, short for Event and Conversion API, is a technical specification from the IAB Technology Laboratory that defines a single, shared way for advertisers to send marketing events to advertising platforms from their own servers. An event is any action a business wants a platform to know about: a purchase, a sign-up, a page view, an app install, a lead becoming qualified. The specification exists because every large platform had built its own server-side conversion pipe, each with different field names, authentication, and matching rules, and an advertiser wanting to feed conversions to several of them had to build and maintain a separate integration for each. ECAPI replaces that pile of one-off connections with one event schema that any receiver can adopt. The IAB Tech Lab finalized version 1.0 on May 3, 2026, and published it in full on GitHub under a Creative Commons Attribution 3.0 license.

The name signals a deliberate widening of scope. Server-side conversion pipes were commonly labelled CAPI, for Conversion API, a term Meta popularised. The working group behind the standard rejected that label as too narrow. According to the specification documentation, the group "didn't think 'CAPI' was representative of the events advertisers find valuable and want to measure or optimize against, so we expanded the scope with the name." What the standard covers is full-funnel activity, from an upper-funnel search or item view down to the purchase, not only the bottom-of-funnel conversion.

Why server-side event sending exists at all

Understanding ECAPI requires understanding the problem the underlying technique solves. For most of the display era, a platform learned that an ad had produced a sale through a pixel, a small piece of JavaScript running in the user's browser that fired a message back to the platform when a tracked action occurred. That browser-based channel has been degrading for years. Ad blockers strip the scripts. Apple's Intelligent Tracking Prevention and successive Safari releases restrict or delete the cookies the scripts rely on. Network-level defences block the endpoints outright: a July 2026 analysis of Safari 27 blocking LinkedIn and Bing ad trackers by IP address put the Bing UET endpoint and the LinkedIn Insight Tag on the exposed list.

Server-side sending routes around all of it. Instead of the browser reporting the event, the advertiser's own server sends it directly to the platform's endpoint, machine to machine. Meta describes the payoff plainly in its documentation, framing the Conversions API as a way to decrease cost per result and improve measurement by connecting marketing data from a server, website platform, mobile app, or CRM. The trade-off is effort: server-side integrations need engineering work, and doing that work once per platform was exactly the burden ECAPI set out to reduce.

How ECAPI works, field by field

The specification adheres to RESTful API conventions. The base protocol is HTTPS, and JSON carries the body of requests and responses, sent with headers of Accept: application/json and Content-Type: application/json. An advertiser transmits an event by making an HTTP POST request to a receiving partner's endpoint. There is no single universal URL: each platform still runs its own endpoint and its own access requirements, and the standard tells advertisers to begin any integration by reviewing that partner's guidance.

At the centre of the payload sits the core event object. The specification marks most fields optional but singles out a handful as required or conditionally required. Three are required in every record. data_set_id is a string, coordinated between the two parties, that names the destination on the receiving system and defines the ID namespace. timestamp is a Unix epoch integer; the spec's worked example is 1746558464, corresponding to May 6, 2025 at 19:07:44 UTC. event_typeis an enumeration value drawn from the standard's event list. A fourth field becomes required conditionally: if event_type is set to custom, the custom_event field must be populated. The specification is explicit about failure. For each of these fields it states that if the value is missing or invalid, "the record may be discarded."

Beyond the required core, the standard defines recommended fields that shape how an event is valued and matched. valueis a float carrying the monetary worth of the event, and when it is set, currency_code, an ISO 4217 code such as USD or EUR, becomes required. source is an enumeration recording where the event happened, with values including website, app, email, phone_call, physical_store, and system_generated. A properties object holds event-specific metadata, and a user_data object carries information used to match the event to a person.

The user_data object is where privacy engineering concentrates. Personally identifying values are not sent in the clear. Email addresses, phone numbers, names, and street addresses are SHA256 hashed before transmission. The standard requires normalization before hashing so that the same input produces the same hash across every participant: lowercase Roman characters, trimmed whitespace, no punctuation, UTF-8 encoding for special characters. Phone numbers must carry a country code and a plus prefix. The object also transports consent state through a gpp_string field holding an IAB Global Privacy Platform consent string and a gpp_sid array naming the applicable sections, alongside event_ip_address, event_user_agent, and a device advertising identifier in ifa.

The event vocabulary is broad. The standard events table lists 28 named types, from purchase, page_view, and add_to_cartthrough the full lead lifecycle of generate_lead, qualify_lead, close_convert_lead, and disqualify_lead, to gaming actions like unlock_achievement. A second additional-events table covers 17 lower-priority types such as share, login, and level_up. The properties object extends further into vertical-specific detail, defining structured fields for travel (departure and arrival dates, IATA airport codes), automotive (body style, fuel type, transmission, VIN), and real estate (listing type, availability). Receivers acknowledge each POST with standard HTTP status codes: 200 for success, 400 for a malformed request, 401 for missing authentication, 429 when a rate limit is exceeded, and 500 for a receiver-side fault.

Deduplication: the field that makes it work

The single most consequential field is one the specification only marks strongly recommended: the event id. When an advertiser reports the same event through two channels, a browser pixel and a server call, the platform needs to know it is one event and not two, or reporting inflates and optimisation degrades. The standard's rule is that the same id value should travel on both the browser record and the server record. A receiving system looks up the combination of data_set_id plus id; if the pair is new, it creates a record, and if the pair already exists, it merges the two.

The spec also handles the case where a shared id is impossible. Where an advertiser cannot guarantee the same identifier across channels, it should submit a given event from a single channel only, rather than risk creating duplicate records. This deduplication logic is precisely the kind of thing each platform previously implemented incompatibly. As Explaining deduplication records, Meta, Google, and TikTok each ran their own matching under different field names before the standard set out to make a shared event id the cross-platform key.

Origin and evolution

The chronology is compressed because the standard is new. The IAB Tech Lab announced ECAPI for public comment on January 20, 2026, framing it, in the words of chief executive Anthony Katsur, as a way to reduce friction and create a shared foundation so teams could spend less time managing integrations. The comment period ran until Friday, February 20, 2026. The working group that produced the draft drew named contributors from Meta, Google, Walmart, Publicis Sapient, NBCUniversal, Paramount, TikTok USA, Roku, and Basis Technology, with Jill Wittkopp, VP Product at IAB Tech Lab, leading the effort. Version 1.0 was finalized on May 3, 2026.

The standard did not emerge in a vacuum. It codifies a practice that platforms had built independently over the preceding years, and the parallel to earlier IAB Tech Lab work is direct: OpenRTB standardised the real-time bidding request years ago, and ECAPI attempts the same consolidation for the conversion signal. The specification was also positioned from the outset as infrastructure for what the Tech Lab calls agentic marketing, where automated agents optimise toward outcomes and need a consistent, machine-readable event feed to do so.

Why it matters to the marketing community

The case for the standard rests on a fragmentation cost that industry research had already quantified. IAB Tech Lab research cited in connection with the specification found that two-thirds of advertisers improved return on ad spend after implementing conversion APIs, and that 72% of publishers identified technical integration challenges as a major obstacle to adopting them. The value was proven; the barrier was engineering effort. A shared schema lowers that barrier, letting an advertiser map its events once and connect to any conformant receiver.

Adoption by the largest receiver signals the stakes. Google has built ECAPI into its measurement stack: Google's Data Strength Uplift metric, announced on September 10, 2026, arrived alongside a universal Data Manager API that Google says is built on the ECAPI standard. Google's own developer documentation, however, exposes where a shared standard still bends to platform reality: its mapping guide notes that ECAPI relies on the id field for deduplication while the Data Manager API relies on transaction_id, and that ECAPI names the destination inside the payload via data_set_id while Google's API uses a separate destinations field. The events are shared; the plumbing around them is not yet identical.

The standardisation also reframes an active platform trend. Server-side conversion sending is spreading beyond the walled gardens, and each new implementation is a candidate for the shared schema. Meta launched a free one-click Conversions API needing no developer; Microsoft gated its own Conversions API behind per-account pilot approval, its documentation carrying an August 4, 2026 last-updated date; and OpenAI published Conversions API and pixel tools for its ChatGPT Ads Manager. The ECAPI explainer notes the direction directly: DIRECTV became the first MVPD to connect to LiveRamp's CAPI Hub for server-to-server signal transmission in April 2026.

Limitations and disputes

The sharpest limitation is one the specification does not hide: it standardises transmission, not consent. ECAPI defines how event data moves, but the legal basis under which that data was collected remains, as the standard's own disclaimer states, the sole responsibility of each implementer. The IAB itself has pressed this point. Analysis tied to the warning that consent is the missing piece in most first-party data strategies makes the boundary explicit: ECAPI carries a GPP consent string, but it does not generate consent, and an advertiser sending hashed emails through a perfectly conformant payload can still be sending data it had no lawful basis to collect.

A second limitation is that the standard is permissive by design, which weakens the interoperability it promises. Almost every field is optional. Receivers are warned in the spec that they may encounter unexpected values, inconsistently populated optional fields, and extension objects that vary by partner. Because platforms may demand their own minimum field sets for particular use cases, "conformant" does not guarantee "accepted": an advertiser can build to the standard and still find a given receiver requires fields the standard leaves out. The extension (ext) mechanism that lets partners add custom fields is the same mechanism that lets platform-specific divergence persist underneath a shared label.

The clean-room extension has already surfaced a concrete defect. On August 5, 2026, the Tech Lab opened for comment a document titled ECAPI Guidelines for Data Clean Rooms, which defines how conversion events should be packaged for upload into clean rooms using Parquet file metadata, with comments closing September 4, 2026. The draft carried an internal inconsistency: its metadata table named the key that declares whether values were hashed or encrypted as ecapi.hash_encrypted, while the encryption section of the same document referred to ecapi.privacy_method for the same purpose. Public comment exists to catch exactly that kind of discrepancy, but its presence in a published draft illustrates how young the surrounding tooling is.

Disambiguation

CAPI (Conversion API) is the older, narrower term ECAPI was created to supersede, and in practice the two are used interchangeably; the specification itself notes ECAPI is "commonly known as CAPI." The distinction the standard draws is scope: CAPI connotes bottom-of-funnel conversions, while ECAPI's remit is full-funnel events.

Meta Conversions API is one platform's proprietary implementation, not the standard. It predates ECAPI, uses its own field names such as event_name and event_time, and remains a distinct product; ECAPI is the industry-wide schema that such proprietary pipes can converge toward.

A pixel is the browser-side counterpart to server-side sending, not a competitor to be chosen instead of it. The standard assumes the two run together, sharing an event id so the platform can deduplicate the browser record against the server record.

OpenRTB is a different IAB Tech Lab standard for a different transaction. It defines the real-time bid request that opens an auction before an ad is served; ECAPI defines the event report that follows after a user acts. One standardises buying inventory, the other standardises measuring outcomes.

Recent developments

Momentum since the May 2026 finalisation has run in two directions: extension of the standard itself and adoption by major receivers. The clean-room guidelines opened for comment in August 2026 mark the first formal extension, taking the same event definitions and specifying how to package them for the privacy-safe matching environments that increasingly sit between advertisers and platforms.

On the adoption side, Google's September 10, 2026 announcement that its universal Data Manager API is built on ECAPI is the most significant endorsement to date, given Google's scale as a receiver of conversion data. In parallel, the wider build-out of server-side infrastructure has continued: X consolidated its Conversion API developer tools inside Events Manager and added Google Tag Manager integration and a live Pixel-and-CAPI diagnostics dashboard in features announced on June 16, 2026, a platform-level response to the same fragmentation the IAB effort addresses at industry level. Whether the standard achieves genuine interoperability or settles into a shared vocabulary layered over persistently divergent implementations remains the open question, and Google's own mapping guide, listing where its API still diverges on deduplication keys and routing, is the early evidence that the answer is not yet settled.

Timeline

  • January 20, 2026: IAB Tech Lab announces ECAPI and opens it for public comment
  • February 20, 2026: The public comment period closes
  • May 3, 2026: IAB Tech Lab finalizes ECAPI 1.0 and publishes the full specification on GitHub
  • June 16, 2026: X announces Google Tag Manager integration and consolidated Conversion API tooling inside Events Manager
  • August 4, 2026: Microsoft's gated Conversions API documentation carries this last-updated date
  • August 5, 2026: IAB Tech Lab opens ECAPI Guidelines for Data Clean Rooms for public comment
  • September 4, 2026: The clean-room guidelines comment period closes
  • September 10, 2026: Google announces a universal Data Manager API built on the ECAPI standard

Summary

Who. The IAB Technology Laboratory produced the specification, led by Jill Wittkopp, with a working group contributing engineers from Meta, Google, Walmart, Publicis Sapient, NBCUniversal, Paramount, TikTok USA, Roku, and Basis Technology. The receivers are advertising platforms; the senders are advertisers, their martech vendors, and infrastructure providers such as LiveRamp.

What. ECAPI, the Event and Conversion API, is a standardised server-to-server specification for transmitting full-funnel marketing events from advertiser systems to advertising platforms. It is built on HTTPS and JSON, defines a core event object with three required fields, uses a strongly recommended event id for cross-channel deduplication, and hashes personal identifiers with SHA256 after normalization.

When. Announced for public comment on January 20, 2026, closed to comment on February 20, and finalized as version 1.0 on May 3, 2026. A clean-room extension opened for comment in August 2026, and Google announced a Data Manager API built on the standard on September 10, 2026.

Where. The specification lives in a public GitHub repository under a Creative Commons Attribution 3.0 license. In operation it runs server-to-server between an advertiser's infrastructure and each platform's own POST endpoint, with an extension defining how events are packaged for data clean rooms.

Why. Every large platform had built an incompatible server-side conversion pipe, forcing advertisers to maintain a separate integration for each while browser-based pixels degraded under ad blockers and tracker restrictions. A single shared schema lets an advertiser map its events once and connect to any conformant receiver, capturing the return-on-ad-spend gains that server-side sending delivers while lowering the integration cost that surveys had identified as the main barrier to adoption.