How to Validate OMID in VAST 4.1-4.3 Tags with VASTlint

Short answer

OMID validation in VAST starts with the XML. If the Verification vendor is malformed, the JavaScriptResource is insecure, the same vendor is duplicated, or verification tracking is wired incorrectly, the measurement stack starts broken before the player has a chance to execute OM SDK.

vastlint can catch the VAST-side OMID mistakes early in the web validator, CLI, npm package, Rust core, and MCP workflow. What it cannot do is prove runtime viewability or compliance by itself. IAB Tech Lab's OM SDK and Google's IMA docs are clear that actual measurement still depends on the player integration, supported access modes, and the measurement provider scripts that run at playback time.

What OMID is doing in the tag

IAB Tech Lab positions OM SDK as the standard measurement layer for digital video, CTV, mobile, and web. The VAST side of that integration is the AdVerifications block: the tag tells the player which verification vendor resources exist, and the runtime exposes measurement signals through the OMID API once playback actually begins.

Google IMA's OM SDK guide is a useful operational reference here. It says the HTML5 SDK automatically parses AdVerifications in VAST tags and sends viewability data to the specified measurement vendors. It also calls out the version split directly: VAST 4.1 and higher should use AdVerifications, while earlier versions can carry the same data inside Extension type="AdVerifications" for compatibility.

Which VAST versions matter for OMID

• VAST 4.1 is where IAB Tech Lab explicitly introduces improved ad verification and ad creative measurement. In normal modern tags, that means AdVerifications and Verification blocks.
• VAST 4.2 keeps the same OMID model while adding SIMID on the interactivity side, which is why teams often think about SIMID and OMID together when replacing VPAID-era payloads.
• VAST 4.3 adds browserOptional on JavaScriptResource, so a validator that understands 4.3 should also know when that attribute is missing.
• If you still receive older VAST documents, some players and SDKs support OM verification via Extension type="AdVerifications" instead of top-level AdVerifications. That compatibility path matters in real traffic, even if your trafficking policy prefers 4.1+.

What OMID XML validation can catch before playback

• Missing Verification vendor attributes or missing verification resources altogether.
• JavaScriptResource or ExecutableResource blocks that omit apiFramework or use a non-OMID value when the resource is clearly meant for OM measurement.
• HTTP verification resources that should be HTTPS in secure runtimes.
• Duplicate vendor identifiers inside the same AdVerifications block.
• Vendor identifiers that are too loose to be useful operationally, such as bare names instead of domain-qualified identifiers.
• Missing or empty VerificationParameters for OMID payloads that need runtime configuration.
• Verification tracking wired to the wrong event model instead of the verificationNotExecuted path used by VAST verification blocks.
• verificationNotExecuted tracking URLs that omit the [REASON] macro, which makes later debugging much weaker than it needs to be.

Why that example is version-specific

The core shape there is VAST 4.1+: Verification vendor, verification resource, optional VerificationParameters, and verification tracking. The browserOptional attribute is the part that matters specifically to VAST 4.3 JavaScriptResource handling.

If your player stack is older, the compatibility question is not just whether the XML is technically well-formed. It is whether the runtime expects AdVerifications directly or an Extension wrapper, and whether the player actually has OM SDK support on that platform.

What the latest OMID rule set should complain about

• VAST-4.1-verification-vendor-format because a bare vendor name like moat is weak compared with a domain-qualified identifier such as company.com-omid.
• VAST-4.1-verification-duplicate-vendor because the same vendor appears twice in one AdVerifications block.
• VAST-4.1-js-resource-apiframework-value because an OM verification resource should declare apiFramework="omid".
• VAST-4.1-js-resource-https because the first JavaScriptResource points at HTTP instead of HTTPS.
• VAST-4.1-verification-parameters because neither Verification includes non-empty VerificationParameters.
• A verification tracking event error because Tracking under Verification is not the same event set as Linear tracking; verificationNotExecuted is the allowed path here.
• VAST-4.1-verification-tracking-reason because the verificationNotExecuted tracker omits the [REASON] macro.

Which vastlint channel to use

• The web validator at vastlint.org/validate is the fastest manual check when ad ops or QA needs to paste a live tag and spot obvious OMID mistakes without installing anything.
• The current published npm package line is 0.4.23. It already catches the core AdVerifications shape: required vendor and resource attributes, apiFramework requirements, and the VAST 4.3 browserOptional warning.
• The deepest OMID coverage in the June 9 release line is in vastlint-core and the CLI at 0.4.24. That adds vendor format, duplicate-vendor detection, VerificationParameters guidance, HTTPS resource semantics, pre-4.1 Extension compatibility checks, and verificationNotExecuted tracking validation.
• If you are gating launches in CI, use the CLI or core first. If you are spot-checking tags with humans, the website and npm package are the easiest entry points. If you are wiring validation into agentic QA, the MCP surface is the right shape.

What OMID XML validation cannot prove

This boundary matters. A valid AdVerifications block is necessary, but it is not the same thing as successful OM SDK measurement in the player. Google's IMA guide says the SDK parses AdVerifications and can apply access mode rules per vendor, which means runtime behavior still depends on the player and SDK configuration rather than XML alone.

That is why the right operational split is: validate the XML before launch, then verify runtime measurement separately in the player or SDK environment you actually ship. vastlint handles the first job. OM SDK compliance and viewability outcomes still require the second.