Skip to main content
A product describes inventory along three independent axes:
  • Publisher properties — WHERE the ad runs (youtube.com, spotify.com)
  • Shows / episodes — WHAT CONTENT the ad runs in or around (a specific series and its installments)
  • Placements — WHAT POSITION the ad appears in (pre-roll, mid-roll, host read)
Shows and placements are parallel dimensions, not hierarchical. “Pre-roll” is a position. “Pinnacle Challenge” is content. A product combines them: “pre-roll on Pinnacle Challenge on Acme Streaming.”

The show object

A show is a persistent content program that produces episodes over time. Shows work like properties — they are reusable objects declared once in a get_products response, and multiple products reference the same show by show_id.

The episode object

An episode is a specific installment of a show. Not all episodes will be known in advance — a weekly podcast may only have next week’s episode scheduled, and some episodes may be tentative (a playoff Game 7 depends on Game 6).

Episode status lifecycle

Expected transitions: scheduled or tentativeliveaired or published. A scheduled episode may become postponed (delayed) or cancelled. A postponed episode returns to scheduled when rescheduled. A tentative episode resolves to scheduled, cancelled, or postponed.

Inheritance from shows

Episodes inherit show-level fields they do not override:
  • content_rating: Episode value overrides show baseline. When absent, the show’s rating applies.
  • guest_talent: Additive to the show’s recurring talent — does not replace it.
  • topics: Additive context for brand safety, not a replacement for the show’s genre.
Buyer agents evaluate both levels: the show baseline provides the default safety profile, and episode fields refine it for specific installments.

How products reference shows

Products reference shows via show_ids — an array, since a single product can span multiple shows (e.g., a network bundle). Episodes are listed per-product in the episodes array, since different products may scope different episodes of the same show.

Run-of-show (no specific episodes)

A product can reference a show without listing episodes. This means “inventory across this show, whatever episodes air during the flight dates”:

Specific episodes

For premium or guaranteed buys, the seller scopes to specific episodes:

get_products response structure

Shows are returned as a top-level shows array in the get_products response, alongside products. Products reference shows by ID instead of embedding them, so the same show is not duplicated when multiple products reference it. The shows array MUST only include shows referenced by the returned products. Under pagination, each page includes all show objects needed for that page’s products.

Discovery examples

CTV show with episodes

A streaming platform selling sponsorships against a known show with upcoming episodes:
A streaming platform offering a main show and its companion after-show, plus highlight clips:
The highlight clip references its source episode via derivative_of. The companion after-show is linked via related_shows on the main show — buyers targeting Nova Kitchen can discover the after-show as an additional reach opportunity.

Podcast with distribution

A podcast network selling across multiple distribution platforms. The show object captures the full distribution footprint:
Tentative episodes (ep48, ep49) have no names or guest info — they have not been produced yet. The buyer evaluates based on the show’s baseline profile and the known details of ep47.

Live event with tentative episodes

A sports league selling sponsorships against a live event series. Live broadcasts use flexible_end because game duration is unpredictable, and unplanned_breaks because ad breaks follow game flow (timeouts, period breaks) rather than a fixed schedule. The tentative Game 5 depends on the series outcome — it only happens if neither team wins in four games.
This pattern combines several features designed for live inventory: cadence: "event" signals a non-recurring series, flexible_end tells buyers the broadcast length is approximate, and unplanned_breaks: true indicates ad breaks follow game flow rather than a predetermined schedule. The tentative Game 5 includes valid_until so buyer agents know when to re-query — if the series ends in four games, that episode will resolve to cancelled. Buyers should always check valid_until on tentative episodes before committing budget.

Discovering shows

Buyers discover shows through the standard get_products workflow. Natural language briefs drive show selection:
The seller returns products referencing shows from the top-level shows array. There is no separate show discovery endpoint — shows surface through product discovery.

Declaring shows in adagents.json

Publishers can declare shows in their adagents.json file alongside properties. This makes the show catalog discoverable for buyers that crawl adagents.json files. Products in get_products responses reference these same show IDs.

Brand safety

Shows provide a two-level brand safety model: a show baseline and per-episode overrides.

Show baseline

A show’s default brand safety profile comes from:
  • content_rating — the show’s declared rating system and value
  • genre — content categories (ideally using genre_taxonomy for machine-readable evaluation)
  • talent — hosts and recurring cast, with optional brand.json references for deeper evaluation
This is what buyers evaluate when individual episode content is not yet known.

Episode overrides

When episode details are available, they can shift the safety profile:
  • A content_rating that differs from the show baseline (this week is TV-14 instead of TV-PG)
  • guest_talent that changes the talent profile (a controversial guest)
  • topics that add episode-specific content signals

What is not modeled

AdCP does not predict content safety for unknown future episodes. A buyer who commits to “all April episodes” buys based on the show’s baseline profile, accepting variation. The seller’s content standards and the show’s track record are the buyer’s basis for that decision.

Distribution identifiers

Each show’s distribution array maps it to specific publisher platforms with platform-specific identifiers. This enables cross-seller matching: when two different sellers both offer products for the same show, a buyer agent can match them via shared identifiers.

Cross-seller matching

Platform-independent identifiers are the most reliable for deduplication: Shows SHOULD include at least one platform-independent identifier when available.

Platform-specific identifiers

Available podcast types: apple_podcast_id, spotify_show_id, rss_url, podcast_guid, amazon_music_id, iheart_id, podcast_index_id. Available video/CTV types: youtube_channel_id, youtube_playlist_id, amazon_title_id, roku_channel_id, pluto_channel_id, tubi_id, peacock_id, tiktok_id, twitch_channel. Other: domain, substack_id.

Ad inventory

Episodes declare break-based ad inventory in the ad_inventory object: For non-break ad formats like host reads, custom integrations, or sponsorships, use product placements instead. A podcast product might have a placement for “mid-roll host read (60s)” — that is a placement on the product, not part of ad_inventory.

Relationship to LEAP

The episode model aligns with IAB Tech Lab’s LEAP Forecasting API for live streaming events: LEAP targets SSP-to-DSP plumbing. AdCP operates at the agent-to-agent negotiation layer where buying decisions happen.

Multi-show bundles

A single product can span multiple shows by listing multiple entries in show_ids. When a product has multiple shows, each episode MUST include show_id so the buyer agent knows which show each episode belongs to.

See also