OpenRTB is the protocol every CTV programmatic auction runs on, but the base 2.x specification was written for web display and video, not television. CTV-specific extensions — content genre signals, pod structure, device type flags, household context — fill the gaps, and a supply path that doesn't pass them correctly loses demand it should be winning. This guide covers the fields, deal mechanics, and creative constraints that actually matter for a CTV bid request, from the perspective of someone configuring DSP-side bidding or publisher-side supply against real television inventory.
CTV-specific bid request fields
OpenRTB 2.6 formalized the CTV extensions that earlier versions left to informal convention: app bundle ID, content genre (IAB content taxonomy), whether the content is livestream or VOD, device type explicitly set to connected TV, and video placement type (in-stream versus accompanying content). None of these are optional in practice. A DSP bidding blind on genre will misfire on kids programming or live news adjacency — the two categories with the tightest brand safety requirements and the steepest penalties for getting it wrong.
Supply paths that don't pass accurate content metadata don't just risk brand safety incidents; they lose bids outright. Buyers with automated brand safety rules will drop any bid request missing genre or content rating fields rather than bid blind, which means an incomplete bid request is invisible to a meaningful share of demand before the auction even runs. LtvAdx enforces content metadata completeness on every bid request it sends, which is part of why supply routed through the platform sees more competitive auction density than supply with gaps in its signal.
Deal IDs, floors, and auction mechanics
Premium CTV inventory rarely clears purely on open auction. The typical sequence is direct-sold first, then programmatic guaranteed deals, then private marketplace (PMP) deals at a negotiated floor, and only then open auction backfill for whatever remains. Each tier uses a Deal ID in the bid request to signal which pre-negotiated terms apply, and the auction resolves tiers in priority order — a mechanism covered in more depth in the deal ID mechanics guide.
Floor prices should be set per app and per pod position, not as a single blanket number across a publisher's entire inventory. First-in-pod and premium content genres can sustain meaningfully higher floors than remnant mid-pod slots; a uniform floor either leaves money on the table for premium inventory or prices out demand for the long tail. Auction timeout matters more in CTV than in web: players buffering an ad break have a hard latency budget, and a demand source that routinely responds slowly gets deprioritized or dropped from the waterfall regardless of how competitive its bids are on paper.
Creative and compliance in the bid response
The bid response carries VAST markup, and CTV players are stricter about what they'll accept than web video players. Declare duration, bitrate, and codec constraints explicitly — a mismatch between declared and actual media file attributes causes some CTV players to drop the creative and fire a VAST error rather than attempt playback. Auto-play audio should never surprise the viewer; living-room ad experiences that startle with sudden volume generate complaints and, on some platforms, policy violations that get inventory deprioritized.
Enforce a maximum ad pod length in the bid response logic, not just at the publisher trafficking layer — a demand source that wins multiple slots in the same pod without a pod-aware cap can push a break well past what viewers tolerate. Tracking pixels must be HTTPS and reachable both from the client player and from the SSAI stitcher when the impression is server-side inserted — an HTTP pixel or an endpoint unreachable from a data center context (common when a tracker is only tested from a browser) silently drops measurement events on every SSAI-delivered impression, which is a broader-than-it-sounds category of CTV inventory.
Testing a CTV OpenRTB integration before it goes live
A bid adapter that's only been tested against sample or synthetic bid requests will find real CTV traffic behaves differently in ways that matter: genre taxonomy values that don't match the expected enum, device type fields set inconsistently across SDKs and SSAI vendors, and content metadata that's present but stale (a live sports feed still tagged with its pre-game genre after kickoff). Validate against real bid request samples from the specific supply paths you'll actually receive, not a generic OpenRTB test harness — the CTV extensions are exactly the fields most likely to diverge between spec and practice.
The LtvAdx OpenRTB integration docs include field-level expectations for every CTV extension the platform sends, along with sample bid requests pulled from production traffic. For teams evaluating whether their existing OpenRTB integration will work against a CTV-native exchange without a rewrite, that's the fastest way to find the gaps before a campaign is live.
