video_hosted) from VAST delivery (video_vast). Placement position such as pre-roll or mid-roll belongs on the product/placement, while the creative declaration describes the accepted payload.
Hosted video
VAST
vast asset with either a URL or inline XML according to the selected declaration. The asset’s singular vast_version is the exact version it supplies. The format option’s plural vast_versions is the accepted set for that product/player path; seller-wide execution.creative_specs.vast_versions is only a ceiling.
Version compatibility is the intersection:
CreativeRepresentationSet resolution is stricter: every VAST candidate declares vast_version, and both the selected product option and seller must advertise non-empty plural sets. Absence means compatibility is unproven, not “all versions.” During migration, producers emit either deprecated singular vast_version for older consumers or plural vast_versions for 3.2 consumers; the two fields are mutually exclusive so they cannot contradict one another.
MediaFile technical acceptance
params.media_file_requirements describes the VAST player’s accepted MediaFile renditions: delivery method (progressive or streaming), MIME type, container, codec, dimensions, bitrate, and maximum exact bytes. For each applicable resolved <InLine> linear creative, at least one <MediaFile> MUST satisfy every declared requirement. Requirements cannot be assembled across siblings: one progressive MP4 may satisfy the delivery, MIME, and codec constraints while a different streaming WebM satisfies the dimensions, but neither is compatible unless one rendition satisfies the full set. Other incompatible sibling renditions do not reject an otherwise compatible creative.
VAST metadata is the first source of evidence: delivery, type, codec, width, height, bitrate attributes, and fileSize where the applicable VAST version provides them. Fixed bitrate must fall within declared bounds; an adaptive minBitrate/maxBitrate interval must be fully contained by those bounds, not merely overlap them. A receiver MAY safely inspect referenced media bytes and MUST prefer the observed byte count if it conflicts with fileSize. It MUST NOT infer a container only from a URI filename extension. When metadata needed for a declared constraint is missing and safe inspection does not establish it, compatibility is unproven; the receiver does not guess.
Omitted MediaFile constraints follow the enclosing declaration’s technical_requirements_complete value. When every applicable declaration layer asserts completeness, omission means no constraint and the seller cannot later reject a conforming creative for an unpublished delivery-method, MIME, container, codec, dimension, bitrate, or file-size rule. Without that complete assertion, omission means undeclared, not unlimited. max_file_size_bytes is always an exact byte count; elsewhere AdCP defines 1 KB as exactly 1,000 bytes and 1 MB as exactly 1,000,000 bytes.
VAST Validation
Format-layer validation ofvast assets is structural: the manifest must satisfy the format’s plural accepted vast_versions set, and validate_input checks manifest shape and declared compatibility. The VAST document itself is opaque at that level, so a structurally valid manifest can still carry an unplayable tag that fails at serve time.
AdCP defines three validation levels for vast assets. Sellers declare the level they perform via creative_specs.vast_validation in get_adcp_capabilities; absent means structural. Validation runs at sync_creatives time, including dry_run. validate_input remains manifest-structure-only at every level.
Document-level validation. Sellers declaring
document or wrapper:
- MUST parse the document (inline
content, or one response fetched fromurl) as XML and reject unparseable documents withVAST_PARSE_FAILED(error.details.reason: "not_xml"). - MUST reject documents whose root element is not
<VAST>withVAST_PARSE_FAILED(error.details.reason: "no_vast_root"). - MUST reject the submitted document when its
<VAST version>attribute is missing or differs from the asset’s singularvast_version. The asset declaration describes this submitted URL response or inline document, not every later wrapper hop. - MUST reject an asset whose
vast_versionis outside the productparams.vast_versionsand sellercreative_specs.vast_versionsintersection withVAST_VERSION_MISMATCH. - MUST emit
mismatch_reason: "asset_outside_acceptance",asset_vast_version,product_vast_versions, andseller_vast_versionsfor an acceptance-set failure. Includeformat_option_refonly when the selected option is addressable; a unique id-less option has no reference to invent. - MUST emit
mismatch_reason: "document_version_mismatch",asset_vast_version, rawobserved_document_vast_version, anddocument_rolewhen an inspected document violates its applicable version rule. Forwrapperandterminal_inlineroles, also emitproduct_vast_versionsandseller_vast_versions, plusformat_option_refwhen the selected option is addressable, because those documents are compared with the acceptance intersection. Usenullwhen the required version attribute is missing; preserve unknown/future strings verbatim for diagnosis.supported_versionsremains a deprecated compatibility field for older 3.x peers. - MUST make
VAST_VERSION_MISMATCHdetails conform toerror-details/vast-version-mismatch.json. - SHOULD reject documents containing no
<Ad>element, and<InLine>linear creatives carrying no<MediaFile>, withVAST_PARSE_FAILED(error.details.reason: "no_ad"/"no_media_file"). - MUST evaluate declared
media_file_requirementsagainst each applicable<InLine>linear creative and reject a creative for which no single<MediaFile>satisfies the full declared set. A document-level check evaluates the fetched document; wrapper-level validation evaluates the terminal resolved<InLine>document. - SHOULD verify that media, tracking, and click URLs use HTTPS.
- MUST preserve undeclared macro tokens as opaque bytes. When an asset supplies
macro_declarations, validate each token against the product and seller macro-resolution capability intersection and report per-token results.
wrapper additionally:
- MUST resolve
<Wrapper>redirects via<VASTAdTagURI>up to the format’s declaredmax_wrapper_depth(when present) and reject deeper chains withVAST_WRAPPER_DEPTH_EXCEEDED(error.details.reason: "depth"). - MUST reject chains that revisit a
<VASTAdTagURI>already seen (a loop) withVAST_WRAPPER_DEPTH_EXCEEDED(error.details.reason: "loop"). - SHOULD apply a per-hop timeout, rejecting with
VAST_WRAPPER_DEPTH_EXCEEDED(error.details.reason: "timeout"), and MUST fetch wrapper hops over HTTPS only. - MUST parse every fetched wrapper and the terminal
<InLine>document, and require each observed document version to be in the product/seller acceptance intersection. Only the submitted document is compared for equality with the asset’s singular declaration; wrapper and terminal documents are not relabeled as the outer asset.
url assets or wrapper hops SHOULD apply the same server-side request protections (private-address blocking, redirect and size limits) they apply to any other agent-supplied URL fetch.
Error codes. In all cases error.field identifies the offending asset path in the manifest.
Vertical and flexible video
Vertical short video is stillvideo_hosted; use width/height or aspect-ratio parameters and, for an exact publisher contract, {publisher_domain, format_option_id}. Equal canonical kind alone is not proof that a generic video builder satisfies a publisher’s duration, codec, slot, or composition constraints.
See Creative representation sets, CTV, Canonical formats, and Creative manifests.