IAB Tech Lab today released the Live Event Ad Playbook (LEAP) Implementation Guide for public comment, a set of documents describing how publishers, advertisers and the technology companies between them should connect two programming interfaces built for live sports and other large streamed events. The comment window closes on Monday, November 23, 2026, 26 days from publication.

The guidance covers the LEAP Forecast API, which describes expected audiences and ad inventory before an event starts, and the Concurrent Streams API, which reports near-real-time stream counts once it is under way. According to IAB Tech Lab, the guide covers "authentication, request and response handling, identifiers, polling, error handling, rate limits, and operational considerations." It does not alter either API. According to the release notes in the project's GitHub repository, the documentation release introduces no changes to the normative API specifications.

ELI5

IAB Tech Lab, a group that writes shared technical rules for online advertising, published instructions for two tools: one tells ad systems how many people are expected to watch a live game, and the other tells them how many are watching right now. When millions of viewers reach the same ad break within seconds, the systems that choose and sell ads can be overwhelmed, so broadcasters, ad sellers and advertisers all have a stake in reading those numbers the same way. Nothing in the guide is final yet, and companies have until November 23 to tell IAB Tech Lab what should change.

What IAB Tech Lab published

The material sits in a public GitHub repository, Live-Event-Ad-Playbook, and IAB Tech Lab points reviewers to iabtechlab.com/leapimplementation. The implementation guidance folder describes itself as "organized around an interactive end-to-end walkthrough, a shared API conventions reference, and API-specific implementation guides."

Four documents make up the release. The Common API Conventions Reference sets rules shared by every LEAP interface: naming, HTTP methods, authentication, formats, status codes, errors, pagination, versioning, rate limiting and sorting. The Forecast API Guidance and the Concurrent Streams API Guidance apply those conventions to each interface. A fourth file, the Multiple API Guidance, points to an interactive walkthrough that follows a single fictional championship broadcast from 30 days out to the moment its stream closes. The repository calls the walkthrough the "Recommended starting point for all readers."

A hierarchy governs conflicts. "If implementation guidance conflicts with an API specification, the API specification takes precedence," the guidance states. Where a common convention and an API-specific guide disagree, the API-specific guide applies for that interface, subject to its specification.

Some housekeeping arrived alongside. According to the release notes, the two specification files were renamed for consistency, to Forecast_API.md and Concurrent_Streams_API.md, and the repository itself was renamed on October 22, 2026 from Live-Event-Ad-Protocols to Live-Event-Ad-Playbook. The guidance lives on the repository's develop branch, which GitHub listed as 53 commits ahead of main on publication day, with the folder's README last edited on October 27.

IAB Tech Lab said the guide was developed through its Live Events Ad Playbook Subgroup. The stated aim is better coordination between publishers, supply-side platforms, demand-side platforms and other partners as live streaming grows. In a post on LinkedIn, IAB Tech Lab thanked "Amazon Ads, The Trade Desk, and Index Exchange for helping advance this work."

Before the event: the Forecast API

The Forecast API is a retrieval interface. A Forecast Data Provider - typically a content owner, streamer, pay-TV distributor or other distributor, according to the specification - publishes an endpoint, provisions authorized partners, and those partners call it on an agreed cadence. Exchanges and DSPs are the expected callers. The guidance states that the API is not meant to define consumer-facing workflows for creating, updating or deleting forecasts.

Two calls do most of the work: GET /eventforecasts for a collection, and GET /eventforecasts/{id} for a single record where supported. Requests carry a required version string such as 1.0.0, a recommended requestor field naming the authorized party, and an optional fdp field to filter by provider when one endpoint serves several. The guide lists query parameters for scheduledstart, scheduledend, lastmodifieddate, eventstatus, id, fdp, limit, offset, sort and order. Its suggested sequence is to discover events within a time window, store the identifiers returned, then poll with lastmodifieddate to fetch only records that have materially changed.

Each event record holds a scheduled start and end, both as Unix timestamps in milliseconds, and a flexibleend flag (0 for fixed, 1 for flexible) for events that can overrun. The content block reuses the AdCOM content object. An eventstatus field takes three values: 1 for scheduled, 2 for tentative and 3 for cancelled. Audience data sits in streamsdata, broken down by country using three-letter ISO codes, with an expectedpeak figure and a lowerbound figure for each. Inventory sits in inventoryconfig: accepted creative formats (1 for banner, 2 for video, 3 for audio, 4 for native), the expected total length of all ad pods in seconds, the estimated number of pods, and an unplanned flag.

The API has no status value for an event that is live or finished. Consumers are expected to infer that an event may already be live, or over, by comparing the scheduled times with the current clock. For events marked flexibleend = 1, the guide asks consumers to allow extra tolerance before treating them as expired.

How much a forecast can be trusted

The guide treats forecasts as probabilistic. It sets out a suggested interpretation by distance from the event:

  • 30 days or more: low stability, used for early planning and budget allocation
  • 14 days: medium-low, used for preliminary deal and infrastructure planning
  • 7 days: medium, used to refine pacing and query-per-second assumptions
  • 24 hours: higher, used to finalize pre-event operational plans
  • Event start: superseded for live concurrency by the Concurrent Streams API

The expectedpeak and lowerbound values describe the event and market as a whole. According to the guidance, they should not be read as guaranteed stream counts for each ad break, since concurrency differs between pre-show, intermission, the final segment, overtime and post-event coverage. Break-level detail can be expressed only where the specification supports it or through an agreed extension.

Tentative games and unplanned breaks

Tentative status exists for events that may not happen. The specification gives the example of a seven-game series decided in five, where games six and seven are never played. The guide describes tentative events as useful for conditional budgets, packages and capacity planning, but not as guaranteed inventory.

The unplanned flag carries more weight than its single bit suggests. According to the guidance, it should be set to 1 when any material portion of inventory may be triggered dynamically or conditionally. Consumers are told to read it as a sign that pod timing may not be fixed, pod counts and total ad duration may vary, and delivery may be uneven across the event. The specification lists game-state-driven breaks in live sports, elastic ad loads and dynamic pod construction as cases for unplanned = 1, while award shows with scripted act breaks and halftime-only sponsorships are cases for 0.

During the event: the Concurrent Streams API

Once a stream opens, a different interface takes over. A Streams Data Provider provisions authorized subscribers, who call GET /concurrentstreams during a live event and receive a timestamped snapshot covering every live event they are entitled to see. The response nests a list of providers, each with a list of media streams, each of which carries the content object, an event start and end, and a streamcount array.

Every streamcount entry has three fields. Region is an integer standing for a coarse traffic area - a broad datacenter region or audience geography - and providers and subscribers are expected to agree on the mapping before production use. The field sstreams holds concurrent streams delivered through server-side ad insertion, and cstreams holds concurrent client-side ad insertion streams. Streams using server-guided ad insertion are counted as server-side for the purposes of the API, according to the guide.

The repository is explicit about what these numbers are not. "Stream counts are not a direct measurement of biddable impressions, programmatic availability, or bid-request volume," the guidance states. Some of the audience will be served direct-sold or guaranteed campaigns, and each party is expected to apply its own programmatic share to both forecast and live figures.

Polling, freshness and caching

How often should a buyer ask? The guide offers a starting table, which it describes as suggested figures for working group review:

  • Pre-event warmup: poll every 5 minutes, treat data older than 10 minutes as stale
  • Live event: every 30 to 60 seconds, stale after 2 minutes
  • Peak moments: every 15 to 30 seconds, stale after 60 seconds
  • Post-event wind-down: every 5 minutes, stale after 10 minutes

Consumers are expected to compare the response timestamp with the time they received it. Aggressive caching during an event is discouraged, although short-lived caches for provider protection are acceptable if their lifetimes match the polling interval. According to the guide, the signals are meant to help consumers scale query capacity, adjust bid throttles, change pacing assumptions, avoid rejecting live bid opportunities because of capacity limits, and detect spikes or drops in stream numbers.

Shared rules for every LEAP interface

The common conventions are deliberately generic. Authentication is left to the provider and is to be agreed with API users before implementation; OAuth 2.0 is described as a common option recommended for consideration, not a requirement. Payloads are JSON in UTF-8, with field timestamps in Unix milliseconds. Responses are expected to carry an X-Request-ID header for tracing, plus X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.

Errors follow a single structure with a code, a message, field-level details and a request identifier. Named codes include INVALID_JSON, MISSING_REQUIRED_FIELD, EXPIRED_TOKEN, INSUFFICIENT_PERMISSIONS and RATE_LIMIT_EXCEEDED. Pagination defaults to 50 results per page with a maximum of 100. Versioning is placed in the URL path, such as /v1/, with breaking changes triggering a new major version, previous versions supported for at least 12 months, and six months' notice before deprecation.

Rate limits get specific numbers. The default thresholds are 1,000 requests an hour per client and a burst limit of 100 requests a minute. A client that exceeds them receives a 429 response with a Retry-After header, and the guide recommends exponential backoff. By PPC Land's calculation, a subscriber polling the Concurrent Streams endpoint every 15 seconds - the fastest suggested cadence - would make 240 calls an hour, and one polling every 30 to 60 seconds would make 60 to 120. Both sit well below the default ceiling, and a single call returns all live events the subscriber can access.

One event, three systems, one identifier

The hardest practical problem the guidance addresses is identity. A forecast record, a live stream count and an OpenRTB bid request all describe the same game, but nothing ties them together unless the parties preserve a shared key.

The guide accepts two methods, and "neither is inherently preferred," in the repository's words. The first is the publisher's content ID, carried as content.id. The second is an Extended Content ID, carried in content.data[].cids[] alongside content.data[].name, which identifies the source of that ID. In bid requests, the same values appear under app.content or site.content depending on the inventory type.

Both approaches have traps. According to the common conventions, a content ID is not automatically universal across unrelated publishers, and comparing only an Extended Content ID string without its source can produce false matches. When both identifiers are present but point to different content, implementers are told to resolve the discrepancy rather than silently treat the records as equivalent. The Forecast API's own event-level id is a separate field: it is recommended to equal content.id where possible, but equality is not guaranteed. And the top-level id of an OpenRTB bid request identifies the auction, not the live event. Event timing and stable metadata may help validate an uncertain match, the guide notes, but they are not unique identifiers.

Deal terms sit outside LEAP altogether. The Forecast API specification says the specifics of deals should travel through the Deal API, which IAB Tech Lab released for public comment in December 2025.

A fictional Game 7, call by call

The walkthrough is where the guidance becomes concrete. It follows the seventh game of a fictional championship final on an invented channel, Sports 2, and every value in it is labelled as made up.

Thirty days out, on October 9, the first forecast call returns a tentative event with an expectedpeak of 1.4 million streams in the US, a lowerbound of 700,000, 10 pods and 1,200 seconds of ad time. A poll on October 25 returns HTTP 304, meaning nothing has changed. By November 1 the series has gone to a seventh game: the event becomes scheduled, the range rises to 1.2 million to 1.8 million and narrows. The final forecast, 24 hours before the event, puts the range at 1.4 million to 1.9 million, with an extra pod lifting the total to 11 pods and 1,320 seconds.

Live snapshots then take over. The stream opens at 00:30 UTC on November 8 with 400,000 concurrent streams. It reaches 1.1 million at the scheduled start, 1.9 million at halftime, when the walkthrough polls every 15 seconds, and 2.4 million in overtime - 26% above the final expectedpeak. The overtime snapshot also shows the event end moving from 05:00 to 05:30 UTC and an overtime break that was never in the forecast; the walkthrough notes that nothing in the API response announces the unplanned break. By the wind-down, streams have fallen 75% to 600,000.

Two worked calculations in the walkthrough show why stream counts matter to infrastructure. If 1.9 million streams reach an opening break within about five seconds, and each stream makes one ad request per pod, the ad server sees roughly 380,000 requests a second. If that ad server calls three SSPs, about 1.14 million requests a second leave it. At halftime, a pod of six 30-second slots across 1.9 million streams caps unique ad opportunities at 11.4 million. A DSP receiving 14.8 million bid requests for that pod is seeing 1.3 times the ceiling, and about 3.4 million requests, or 23%, are duplicates arriving through several supply paths or re-sent after timeouts.

The post-event review compares the saved snapshots. The forecast moved closer to reality as the event approached, and its range narrowed from 700,000 to 500,000, yet the final number still came in 26% low at the top end. The walkthrough's lesson is to plan capacity above expectedpeak for events flagged flexibleend = 1, because overtime brings extra streams and extra pods at the same time.

Loose ends the documents acknowledge

The guide is candid about inconsistencies in its own foundations, and a close reading turns up a few more.

The most significant concerns direction of travel. The Forecast API v1.0 specification describes broadcasters and streamers pushing their live events manifest into exchanges, and exchanges pushing it on to DSPs. The implementation guide describes a pull model throughout, in which partners call the provider's endpoint. A note in the Forecast API guidance acknowledges that the specification's push language is inconsistent with the guides and says it will be cleared up in the next iteration of the specification.

The specifications' JSON samples also drift from their own field tables. In the Forecast API specification, the tables define an events array and an inventoryconfig object, while the samples use an upcomingevent array, an adinventoryconfig object and a media_types_supported field holding text values such as video and display instead of the integer codes. The Concurrent Streams specification's sample places stream counts and timestamps inside quotation marks and uses ten-digit timestamps, a seconds format, although the field is defined in milliseconds. The new guidance examples use the table names, integer values and millisecond timestamps throughout.

Wording has softened in at least one place. The Concurrent Streams specification makes the presence of at least one of sstreams or cstreams mandatory, while the guidance turns that into a recommendation. Under the repository's own hierarchy, where the specification prevails in any conflict, the stricter wording would apply.

Status is not fully settled either. According to the release notes, Concurrent Streams API v1.0 became LEAP's first final specification in the third quarter of 2025, though the exact publication day was not confirmed in the sources the notes reviewed. For the Forecasting API, the notes record that public comment closed on March 20, 2026, and state that the closure by itself does not establish a verified final v1.0 publication date. The walkthrough's footer, meanwhile, describes both as draft specifications. Smaller gaps remain: the walkthrough relies on a 304 Not Modified response to conditional requests, a code that does not appear in the common conventions' list of status codes.

The announcement itself leaves one question about sequencing. IAB Tech Lab lists Phase Three, "focused on implementation guidance," among the next stages it wants industry participants to contribute to, on the same day it published implementation guidance. The release does not say whether this guide completes that phase or opens it.

What the companies said

Four executives were quoted in IAB Tech Lab's announcement. Shailley Singh, EVP, Product, and COO at IAB Tech Lab, framed the guide as a step from progress to practice. "Live sports and other major events are becoming a bigger part of streaming, and the industry needs the infrastructure to keep up," Singh said. "When buyers and sellers can work from the same technical playbook, they can spend less time figuring out integrations and more time creating better advertising experiences for viewers."

Rob Hazan, General Manager, Product Management at The Trade Desk, said: "We've been strong supporters of LEAP because common standards help everyone move faster. Giving buyers and sellers clearer guidance on how to implement these APIs is an important step toward making live event advertising more predictable, efficient, and scalable."

Pramod Jagtap, Principal Engineer at Amazon Ads, pointed to the mechanics. "Running ads during major live sporting events, where millions of viewers arrive at once, shows how quickly small inconsistencies in API implementation become real coordination problems," Jagtap said. According to Jagtap, the guide "shortens integrations and lets partners line up quickly when timing matters most."

James Wilhite, VP of Product at Index Exchange, described the pressure on the supply chain. "When millions of viewers reach the same ad break within seconds, the infrastructure needs to be ready to handle those sudden surges in demand," Wilhite said. "LEAP enables the industry to plan around shared forecasts and respond to real-time signals, helping the entire ecosystem scale together."

None of the documents names a company running either API in production, and none gives adoption figures.

How LEAP got here

LEAP is more than a year old. According to the release notes, public comment on the Concurrent Streams API closed on July 28, 2025, and IAB Tech Lab announced the playbook on August 5, 2025, in collaboration with Amazon, NBCUniversal, FreeWheel and Index Exchange. NBCUniversal and FreeWheel are not among the three companies thanked for today's guide.

Weeks later, at IAB Tech Lab's CTV ad operations workshop, live event delivery was one of six technical barriers to programmatic CTV identified by participants. At that point the Concurrent Streams API had been released, the Forecasting API was still to come, and bid pre-fetching was described as a future capability. IAB Tech Lab opened the Forecasting API for public comment on February 19, 2026, with comments due by March 20. A GitHub release titled Concurrent Streams v1 followed on July 28, 2026, which the release notes record separately from the 2025 milestones.

The release lands in a crowded comment calendar. IAB Tech Lab extended comments on AAMP 3.0, its agentic ad-buying framework, to November 10, so two of its consultations now overlap for nearly two weeks.

Why this matters for the marketing community

The operational problems LEAP addresses have surfaced repeatedly in PPC Land's coverage of live sport. Magnite reported that 37 media owners had scheduled and monetized more than 4,000 live events on its platform since November 2025, and that global live sports ad spend on its platform rose 56% from January to July 2026. Amazon said its inventory for Thursday Night Football, the NBA, the WNBA and NASCAR sold out during the second quarter of 2026, with Prime Video claiming 315 million ad-supported viewers worldwide.

The request-volume arithmetic in the walkthrough also echoes earlier work on waste. StackAdapt reported a 71% average QPS reduction after adopting ad podding with Index Exchange in July 2025, and A+E Global Media reported an 84% cut in inbound ad server requests after moving to pod-level auctions. In April 2026, Amazon Ads donated its Dynamic Traffic Engine to IAB Tech Lab to let DSPs signal which bid requests they value. LEAP approaches the same pressure from a different angle: knowing how many people are about to hit an ad break before the requests arrive.

Ad insertion architecture adds another layer. When IAB Australia published its explainer on server-guided insertion in August 2026, it flagged that the Concurrent Streams API counts SGAI streams inside SSAI figures, which can complicate reporting, and noted that LEAP's pre-fetch and creative-readiness phases had not yet been delivered. Today's guide confirms the first point as intended design and leaves the second for later phases.

The 2026 World Cup showed how unusual live ad windows can be. FIFA approved ads during hydration breaks in all 104 matches, creating 208 commercial windows with roughly two minutes of usable time each, and iSpot later found that hydration break pods retained viewers better than halftime or extra-time slots. Breaks of that kind are the unplanned, condition-driven inventory that the Forecast API's unplanned flag is meant to describe.

For buyers, the practical value of LEAP depends on two things the documents cannot supply: how many streamers and distributors publish the feeds, and whether the identifiers in those feeds reach the bid request intact. The guidance standardizes the vocabulary. Adoption remains voluntary.

What comes next

IAB Tech Lab said LEAP will continue through further phases. The announcement names Phase Three, focused on implementation guidance, and Phase Four, focused on creative readiness, along with continued development of version 1.1 of both the Forecasting and Concurrent Streams APIs. Future work will also address standardized ad pre-fetching for live streaming environments. Feedback on the current guide is due by Monday, November 23, 2026, through the LEAP implementation page, and the repository lists support@iabtechlab.com as its contact for questions and participation.

Timeline

Summary

Who: IAB Tech Lab, the digital advertising technical standards body, with acknowledged contributions from Amazon Ads, The Trade Desk and Index Exchange. The guidance is aimed at streamers, content owners, distributors, ad servers, supply-side platforms, demand-side platforms and advertisers that transact live event inventory.

What: The Live Event Ad Playbook (LEAP) Implementation Guide, a set of four documents and an interactive walkthrough explaining how to implement the LEAP Forecast API and Concurrent Streams API. It covers authentication, identifiers, polling cadences, error handling, rate limits of 1,000 requests an hour and 100 a minute by default, and how to tie forecasts, live stream counts and OpenRTB bid requests to the same event. It changes neither API specification and acknowledges several inconsistencies in them.

When: Released today for public comment, with feedback due by Monday, November 23, 2026. LEAP itself was announced on August 5, 2025.

Where: Published on GitHub in IAB Tech Lab's Live-Event-Ad-Playbook repository and on IAB Tech Lab's website, with an interactive walkthrough on GitHub Pages. The announcement was datelined New York.

Why: Live events concentrate audiences into ad breaks that can draw millions of requests within seconds. IAB Tech Lab says consistent implementation reduces integration complexity and lets buyers and sellers plan for live inventory in advance and adjust to viewership changes as they happen.