Guides
The VAST tag
Request a video ad with GET /vast on your serving domain. Include the publisher, placement, and supported media types, plus any player and privacy parameters. A filled request returns VAST 4.2 with tracking URLs; no fill returns HTTP 204.
The request
Use a VAST tag when your video player accepts an ad-tag URL. The example requests an MP4 ad for a 1280×720 player. A filled response gives the player the media and event URLs it needs; an empty response lets it continue without an ad. Use a configured sandbox placement to check the tag before adding it to your player.
GET https://ads.acme.example/vast?pub=acme-pub&tag=acme-preroll&mimes=video/mp4&w=1280&h=720
User-Agent: Mozilla/5.0 (a real player or browser)
The serving domain is the tenant's own (Settings, Brand and domains). Public ids are the strings you chose
when creating the publisher and placement; the sample data uses <slug>-pub and
<slug>-preroll. Try it from the CLI: riptide tag --serve https://ads.acme.example --pub acme-pub --tag acme-preroll
prints the URL and a curl command. Use your player's User-Agent for live requests;
requests with known bot User-Agents return HTTP 204.
| Required | Meaning |
|---|---|
pub | Publisher public ID, shown on the publisher’s console page. Use this string rather than the resource UUID. |
tag | Placement public id. |
mimes | Comma-separated media types the player accepts, e.g. video/mp4,video/webm. |
| Optional | Meaning |
|---|---|
w, h | Player size; a tag without one gets the CTV/app default for its inventory kind. |
min_dur, max_dur | Duration bounds in seconds (defaults apply when omitted). |
floor, cur, mincpmpersec | Floor as a decimal CPM, its currency, and a per-second floor for pods. |
pod, podseq, slotinpod, poddur, maxseq | Ad-pod identity and slot position for server-side pods. |
plcmt, protocols, api, ssai | OpenRTB 2.6 video placement subtype, supported VAST protocols and APIs, SSAI hint. |
ip, ua, ifa, dnt, lmt, devicetype, make, model, os, osv | Device signals when the tag is called server-side; on a client the request's own headers are used. |
gdpr, gdpr_consent, us_privacy, gpp, gpp_sid, coppa | Privacy signals; consent gates targeting and user-sync. |
schain, ipd | Supply chain (serialized) and inventory partner domain. |
dsarequired, dsapubrender, dsadatatopub, dsatransparency | DSA transparency request. |
content_id, content_title, genre, rating, language, network, channel, cat, kw | Content and contextual signals for targeting. |
bundle, storeurl, appname, domain, url, pubuid | App or site identity and the publisher's own user id. |
tmax, test, demo, nolog | Auction deadline in ms, test traffic (never billed), demo fill, and no event logging. |
The response
A fill is a VAST 4.2 document: InLine ads carry an Impression, quartile and click trackers on
the tenant's event domain (signed and deduplicated; see the beacons guide) and
the creative's MediaFiles; a wrapper creative answers a Wrapper with its
VASTAdTagURI. Every document carries the platform Error URL. A no-fill is a
body-less 204; a malformed tag is 400 with the typed error envelope naming
the parameter. Placements can be paused per protocol (VAST, OpenRTB) from the console.
Check a fill
riptide conformance vast --serve https://ads.acme.example --pub acme-pub --tag acme-prerollThe probe fetches the tag with a browser User-Agent and reports each check: HTTP 200 with XML, VAST 4.x, at least one ad, an Impression, and a MediaFile per InLine ad. For a walkthrough that starts with sample inventory, follow the CLI guide.
Connect through OpenRTB
If your bidder or wrapper exchanges OpenRTB requests, use the OpenRTB guide for request fields and bid responses. The serving probe lets you check both VAST and OpenRTB responses.