OpenRTB selects the bid and VAST tells the player how to serve the video ad

VAST and OpenRTB meet at the handoff from auction to playback. In OpenRTB 2.x, a seller describes a video impression in a bid request and bidders return offers. The winning offer can deliver a VAST document as its ad markup. The player or server-side stitcher then reads VAST to find media files, impression URLs, tracking events, and any wrapper to resolve. A valid bid does not prove that the VAST will play.

Where VAST appears in an OpenRTB transaction

1. Supply offers video inventory. An OpenRTB bid request includes an imp object with a video object describing the opportunity and its constraints.
2. Bidders return offers. A bid response can include price and creative markup in seatbid.bid.
3. The exchange selects a winner. The winning markup reaches the supply path. For video, that markup can be a VAST document.
4. The player or stitcher consumes VAST. It resolves wrappers, selects a supported media file, plays or stitches the ad, and handles tracking.

IAB Tech Lab's OpenRTB 2.6 specification explicitly lists a VAST document as possible video or audio markup. It defines two ways to deliver that markup: inside bid.adm, or in the response body obtained from bid.nurl when markup is served on the win notice. When adm is present, it takes precedence over markup returned by the win notice. The integration partners decide which method they support.

Read a bid without confusing the JSON envelope with the ad

This abbreviated response shows the boundary. The value of adm is an XML string inside JSON. The ellipsis stands for the rest of a real VAST response, so this excerpt is for reading the handoff, not for playback.

{
  "id": "auction-42",
  "seatbid": [{
    "bid": [{
      "id": "bid-1",
      "impid": "video-slot-1",
      "price": 12.50,
      "adm": "<VAST version='4.2'>...</VAST>"
    }]
  }]
}

{
  "id": "auction-42",
  "seatbid": [{
    "bid": [{
      "id": "bid-1",
      "impid": "video-slot-1",
      "price": 12.50,
      "adm": "<VAST version='4.2'>...</VAST>"
    }]
  }]
}

The exchange checks the JSON and auction fields. A VAST validator must extract and unescape the adm string before checking it as XML. This distinction matters in incident reports: "the bid was accepted" and "the ad played" are separate observations. Some supply paths instead call a VAST ad tag URL directly. OpenRTB may still run upstream of that URL without appearing in the player's network trace.

An auction win is not a video impression

A nurl win notice says that the auction selected a bid. The ad can still fail to load, fail to decode, time out in a wrapper, or never reach a viewer. IAB Tech Lab's OpenRTB implementation guidance says not to count wins as served impressions. For VAST video, the VAST impression event is the official signal for the billable impression. This distinction is especially important in CTV, where a winning bid may be followed by a stitcher that rejects the supplied asset.

Which system should validate each layer?

• Before the auction: validate the OpenRTB request and response against the protocol and partner rules. A VAST validator does not decide whether a bid price or targeting field is acceptable.
• At creative intake: extract VAST markup from adm or the returned ad markup and run a VAST specification check.
• Before playback: use the live tag tester for fetch and preview, or the wrapper inspector for redirect chains. XML alone cannot prove that a remote media URL works.
• At the stitcher: check codec, media type, duration, mezzanine availability, and beacon behavior against the actual SSAI environment.

vastlint validates the VAST side of this boundary. Its verdict is not an OpenRTB conformance verdict, an auction result, or a guarantee of playback. For a worked VAST document, see how VAST differs from generic XML.

When should a publisher use a VAST tag or an OpenRTB endpoint?

That is an integration choice, not a choice between equivalent standards. A publisher can connect a player to a VAST ad server or connect a supply platform to bidders over OpenRTB. A programmatic video path often uses both: OpenRTB selects demand, while VAST carries the winning ad to the player or stitcher. Ask which component receives the request, which component makes the decision, and which component must read the VAST.

Sources

• IAB Tech Lab OpenRTB 2.6, ad serving options
• IAB Tech Lab OpenRTB implementation notes, billable events
• IAB Tech Lab VAST specification