VASTlint

VAST examples / Required fields

A <VAST> root element with no version attribute

VAST 2.01 error1 warningVAST-2.0-root-version

The scenario

An ad-tech integrator was onboarding a new demand partner whose tags intermittently broke a downstream wrapper-unwrapping service. The partner's spots looked fine in a browser but failed inside the exchange's normalization layer.

The broken tag

<?xml version="1.0" encoding="UTF-8"?>
<!-- Missing version attribute on VAST element -->
<VAST>
  <Ad id="1">
    <InLine>
      <AdSystem>Test AdServer</AdSystem>
      <AdTitle>Test Ad</AdTitle>
      <Impression><![CDATA[https://example.com/impression]]></Impression>
      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:30</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4" width="640" height="360">
                <![CDATA[https://example.com/video.mp4]]>
              </MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

What the validator reports

Running this tag through vastlint produces the following. The primary failure for this example:

errorVAST-2.0-root-versionIAB VAST 2.0 §2.1line 3

Root <VAST> element is missing the required version attribute

The same tag also surfaces these secondary findings — real tags rarely fail in isolation:

warningVAST-2.0-linear-tracking-quartilesIAB VAST 4.1 §3.14.2line 11

<Linear> has no standard quartile tracking events (start/firstQuartile/midpoint/thirdQuartile/complete) — ad will serve but measurement system receives no signal

Why it breaks

The root element is <VAST> but it carries no version attribute. The version attribute tells every consumer which VAST schema and feature set to expect (2.0 through 4.3), and it is required on the root. Tolerant players may assume a default, but strict normalizers and validators cannot choose a schema and reject the document outright.

What it costs

Because behavior depends on how forgiving each consumer is, the same tag works in casual testing and fails inside strict middleware — the hardest class of bug to diagnose. The unwrapping service discards the response, so any ad behind that wrapper never serves, and the demand partner appears to under-deliver for reasons that never show up in a simple browser check.

The fix

Add the version attribute to the root element matching the features you actually use. If the creative relies on 4.x features (UniversalAdId, AdVerifications), declare 4.0 or higher rather than 2.0.

<!-- wrong: <VAST> -->
<!-- right: declare the schema version -->
<VAST version="4.2">
  ...
</VAST>

Check your own version of this tag

Paste the resolved XML to run the same spec check, test a live tag URL, or inspect the wrapper chain hop by hop.

Validate this XML →Test this live URL →Inspect this wrapper chain →

Related examples

Related reading