- 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)
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 aget_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 tentative → live → aired 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 recurringtalent— does not replace it.topics: Additive context for brand safety, not a replacement for the show’sgenre.
How products reference shows
Products reference shows viashow_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-levelshows 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:Related shows and derivative content
A streaming platform offering a main show and its companion after-show, plus highlight clips: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:Live event with tentative episodes
A sports league selling sponsorships against a live event series. Live broadcasts useflexible_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.
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 standardget_products workflow. Natural language briefs drive show selection:
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 inget_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 valuegenre— content categories (ideally usinggenre_taxonomyfor machine-readable evaluation)talent— hosts and recurring cast, with optional brand.json references for deeper evaluation
Episode overrides
When episode details are available, they can shift the safety profile:- A
content_ratingthat differs from the show baseline (this week is TV-14 instead of TV-PG) guest_talentthat changes the talent profile (a controversial guest)topicsthat 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’sdistribution 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
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 thead_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 inshow_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
- Media products — the full product model
- brand.json — talent identity and brand safety evaluation
- Product discovery — how buyers discover inventory via
get_products