The IAB Technology Laboratory last month has finalized version 1.0 of the Event and Conversion API specification - commonly referred to as ECAPI - marking the end of a public comment period that closed on Friday, February 20, 2026. The specification, developed by a working group drawing contributors from Meta, Google, Walmart, TikTok, Roku, NBCUniversal, and Paramount, establishes a shared technical framework for server-to-server transmission of marketing-related events from advertisers to advertising platforms and partners.

The specification is now available for implementation and published in full on GitHub.

What ECAPI is, and why it exists

The core problem ECAPI addresses is fragmentation. Conversion APIs - the server-side mechanism by which advertisers share event data such as purchases, leads, and page views with platforms - have existed for years. Meta, Google, TikTok, and others each built their own. An advertiser managing campaigns across multiple platforms faced a separate integration for each one: different field names, different event taxonomies, different deduplication logic. According to the IAB Tech Lab's blog post accompanying the specification, "the much-needed ability of advertisers to communicate marketing-related events and customer behavior to publishers and platforms is impacted" by the shift away from client-side tracking, and server-side signals - previously siloed in CRMs and internal databases - needed a standardized path to reach media partners.

The IAB Tech Lab Working Group considered the name "CAPI" 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." The result covers full-funnel activity, not just bottom-of-funnel conversions.

The technical structure of ECAPI

ECAPI is built on HTTPS and JSON, following RESTful API conventions. Advertisers send a POST request to a partner's endpoint. The core event object contains a small set of required fields and a larger set of recommended or optional ones.

Three fields are required in every event record: data_set_id, a string that identifies the destination on the receiving system and defines the ID namespace; timestamp, expressed as a Unix epoch integer - the specification gives the example 1746558464, corresponding to May 6, 2025 at 19:07:44 UTC; and event_type, an enumeration value drawn from the spec's standard event list. If the event_type is set to "custom", a fourth field, custom_event, becomes required. If any of these required fields are missing or invalid, according to the specification, "the record may be discarded."

Beyond the required fields, the spec designates several as "strongly recommended." The event id field - any unique string chosen by the advertiser - is central to deduplication. When both a server-side event and a browser pixel fire for the same user action, both records should carry the same id value. The receiving platform then merges the records rather than counting the conversion twice. The spec is explicit: "If it is not possible to provide the same ID for the event across multiple channels, advertisers should only submit a given event from a single channel to avoid creating multiple records for the same event."

Monetary fields - value and currency_code - are recommended. The currency_code must be a valid ISO 4217 code, and if value is present but currency_code is absent or invalid, the spec notes the record may be discarded.

A taxonomy of 27 standard events and 15 additional ones

One of ECAPI's most practically significant contributions is its event taxonomy. The specification defines 27 standard events covering the complete marketing funnel. At the bottom of the funnel, purchase, generate_lead, qualify_lead, close_convert_lead, and subscribe represent the outcomes advertisers care most about. Mid-funnel events include begin_checkout, add_payment_info, add_to_cart, viewed_cart, and viewed_item. Upper-funnel events include page_view, ad_impression, and search. The spec also covers app-specific events such as install, as well as lifecycle events like sign_up, start_trial, and schedule.

A secondary table of 15 additional events - deemed "generally lower priority" but still worth standardizing - covers actions such as add_shipping_info, login, join_group, and gaming-specific events including level_up, post_score, and earn_virtual_currency. For scenarios not covered by the taxonomy, the custom event type allows advertisers to define their own, provided the custom_event string field is populated.

User data, privacy signals, and hashing requirements

The user_data object sits at the center of privacy-sensitive data handling. It carries hashed identifiers: email addresses, phone numbers, first name, last name, street address, and postal code must all be SHA256 hashed before transmission. The specification is precise about normalization requirements prior to hashing - inputs must use lowercase Roman alphabet characters, whitespace must be trimmed, and no irrelevant formatting or punctuation should remain. Phone numbers must include the country code with a plus prefix, regardless of whether all data originates from a single country.

The spec includes a gpp_string field and a gpp_sid array field, directly integrating with the IAB's Global Privacy Platform consent signaling infrastructure. A boolean mmt_only field - flagged as "may be required in relevant jurisdictions" - instructs receiving systems to use the event only for attribution, not for ads delivery optimization. This field has clear implications for GDPR-compliant deployments where consent to optimize ad delivery has not been granted.

An event_ip_address field accepts valid IPv4 or IPv6 addresses corresponding to the event. Separate landing_ip_address and landing_user_agent fields capture the consumer's state at the time they accessed the campaign landing page, distinct from the conversion moment itself.

Items, properties, and vertical-specific fields

The properties object extends the event payload with transaction-level and item-level metadata. A nested items array uses the item object, which supports product identifiers, pricing, discount values, quantity, brand, category, and affiliation fields. The cattax field within item references the AdCOM 1.0 Category Taxonomies, with IAB Tech Lab Ad Product Taxonomy 2.0 recommended as the default.

The properties object also covers travel-specific fields - arrival_date, departure_date, and destination_airport using IATA codes - as well as an extensive set of automotive fields covering body style, drivetrain, fuel type, transmission, VIN, make, model, exterior color, and lease dates. Real estate listing types are enumerated separately. These vertical extensions indicate the spec was designed with retail, automotive, and travel advertisers specifically in mind, not only e-commerce.

Deduplication, batching, and response codes

The spec dedicates a section to how receiving platforms should handle ID-based record matching. When a platform receives a record with an ID, it looks up the combination of data_set_id and id to determine whether this is a new or existing event. If found, records are merged; if not, a new record is created. Merge rules are implementation-specific. Platforms may set update time limits and discard records with IDs matching records that exceeded those limits.

Batch transmission is supported for use cases such as offline retail events or CRM-based lead qualification, where real-time event firing is impractical. Advertisers should consult platform-specific documentation for batching format requirements.

Six HTTP status codes define the response vocabulary: 200 for success, 400 for unparseable requests, 401 for authentication failures, 404 for missing resources, 429 for rate limit violations, and 500 for server-side errors.

Who contributed and how the spec was built

The specification was developed under the IAB Technology Laboratory, a nonprofit research and development consortium. Jill Wittkopp, VP Product at IAB Tech Lab, led the effort. Significant contributors include Steven Ware Jones and Sean Bedford from Meta; Alan Merzon and Chandan Giri from Google; Akchat Jha from Walmart; Barbara Kalicki from Publicis Sapient; Melissa DeLuca from NBCUniversal; Celina Mbale from Paramount; Steve Huang from BD TikTok USA; Matt Reid from Roku; and Randy Weinstein from Basis Technology.

That contributor list spans buy-side platforms, sell-side media companies, independent agencies, and retail technology - an unusually broad coalition for a single API specification. Brian May is also listed as a contributor without affiliation in the document.

According to the IAB Tech Lab blog post by Melissa DeLuca of NBCUniversal, Sophia Lehman of Attain, and Shikha Bhargava of Warner Brothers Discovery, "every integration built to a shared spec is one less integration that has to be scoped, negotiated, and engineered from scratch." The post frames ECAPI not as an incremental update but as a compounding efficiency gain across the industry over time.

The specification is licensed under a Creative Commons Attribution 3.0 License. Extension objects - ext fields included at the end of every object definition - allow implementation-specific customization without breaking the shared structure. Platform-specific fields can be accommodated within the ext object, which means adoption does not require rebuilding existing integrations from scratch.

Why this matters for the marketing and advertising community

The marketing industry has been building toward this kind of standardization for years. As PPC Land documented in October 2025, the IAB had already urged industrywide CAPI adoption specifically for connected television, with two-thirds of advertisers reporting improved return on ad spend after implementation. That October 2025 guide identified a structural problem: CAPI existed as a concept but not as a shared standard, leading to siloed implementations across platforms.

The signal loss context matters here. IAB Tech Lab's work on privacy-first advertising frameworks has consistently identified the shift away from client-side tracking as a structural challenge for measurement. ECAPI represents the server-side counterpart to that work - not a privacy-enhancing technology, but a standardization layer that makes server-side signals interoperable across the ecosystem.

Meta's own April 2026 updates to its Pixel and Conversions API demonstrated the gap ECAPI is designed to address. Meta's proprietary CAPI setup required significant technical resources to implement, and the one-click setup was needed precisely because the complexity had become a barrier. A shared specification reduces that barrier at the industry level, not just within a single platform.

Innovid's November 2025 expansion of conversion signals for CTV cited IAB Tech Lab research noting that 72% of publishers identified technical integration challenges as a major obstacle to CAPI adoption. ECAPI directly targets that obstacle by defining a single payload structure that platforms can accept as a standard inbound format.

DIRECTV's connection to LiveRamp's CAPI Hub, announced in April 2026, illustrates the broader direction: media companies building server-to-server infrastructure to receive conversion signals directly from advertisers, bypassing browser-based measurement entirely. ECAPI gives that infrastructure a shared language.

The specification also addresses the lead management use case explicitly, with events covering the full lead funnel: generate_lead, qualify_lead, working_lead, close_convert_lead, disqualify_lead, and close_unconvert_lead. This is notably more granular than what most proprietary CAPI implementations support, and it signals that the spec was designed for B2B and service-industry advertisers, not just e-commerce.

What adoption looks like in practice

According to the IAB Tech Lab blog post, for advertisers and data intermediaries already sending server-side events, "adoption is straightforward. In most cases, it starts as a mapping exercise: review your event taxonomy against ECAPI's standard event types, map user fields into the user_data object, and align your event_id strategy with the spec's deduplication approach."

For publishers and platforms, the post notes that supporting ECAPI-formatted payloads "does not mean rebuilding existing integrations from scratch." The ext object accommodates platform-specific fields.

The spec itself emphasizes that while most fields are optional, partners and platforms may impose their own minimum field requirements for specific business use cases, and "it is expected that they will communicate to partners these minimum requirements." This means ECAPI sets the floor - individual platforms set their own ceilings.

Timeline

  • January 29, 2025 - IAB Tech Lab announces 2025 technical standards roadmap with 31 planned specification releases, including a universal CAPI standard for CTV as a stated priority. PPC Land
  • August 27, 2025 - IAB Tech Lab CTV Ad Ops Workshop identifies absence of a universal CAPI standard as one of six critical barriers to CTV's programmatic potential. PPC Land
  • October 30, 2025 - IAB releases 26-page guide on Conversion APIs for CTV, reporting two-thirds of advertisers improved ROAS after CAPI implementation. PPC Land
  • November 5, 2025 - Innovid expands Harmony with conversion signals; IAB Tech Lab research cited showing 72% of publishers identify technical integration as a major CAPI adoption barrier. PPC Land
  • Late 2025 / early 2026 - ECAPI specification enters public comment period.
  • February 20, 2026 - Public comment period for ECAPI 1.0 closes.
  • April 15, 2026 - Meta announces one-click Conversions API setup and AI-enhanced Pixel, targeting technical barriers to CAPI adoption for smaller advertisers. PPC Land
  • April 2026 - DIRECTV becomes first MVPD to connect to LiveRamp's CAPI Hub for server-to-server conversion signal transmission. PPC Land
  • May 3, 2026 - ECAPI 1.0 specification finalized and available for implementation; full specification published on GitHub.

Summary

Who: The IAB Technology Laboratory, a nonprofit standards consortium, finalized ECAPI 1.0 with significant contributions from Meta, Google, Walmart, TikTok USA, Roku, NBCUniversal, Paramount, Publicis Sapient, Basis Technology, and Warner Brothers Discovery, among others. Jill Wittkopp, VP Product at IAB Tech Lab, led the specification effort.

What: ECAPI 1.0 is a standardized server-to-server API specification for transmitting marketing-related events - including purchases, leads, page views, app installs, and custom actions - from advertisers to advertising platforms. It defines a core event object, a taxonomy of 27 standard and 15 additional event types, a user data object with SHA256 hashing requirements, and response code conventions. The specification includes an extension object to allow platform-specific customization without breaking the shared structure.

When: The public comment period closed on February 20, 2026. The specification was finalized and made available for implementation as of May 3, 2026.

Where: The specification is published on GitHub at the IAB Tech Lab's public repository and applies globally to any advertiser-to-platform integration using server-side event transmission.

Why: Conversion APIs had proliferated across the industry without a shared standard, requiring separate integrations for each platform. As client-side tracking faces growing constraints from privacy regulations and browser restrictions, server-side event transmission has become increasingly important for measurement and optimization. ECAPI provides a single shared payload structure that reduces integration overhead for advertisers, publishers, and platforms operating across multiple partnerships.

Share this article
The link has been copied!