Written for the people who will actually do the integration — platform engineers and ad operations. Concepts and standards here; endpoint-level reference is linked at the bottom.
Which page you want depends on what you are trying to establish.
The integration paths available, what each one requires from your player or packager, and which one fits your setup.
How stitching works at the manifest level, what it demands of your packaging pipeline, and where it goes wrong.
VAST, VMAP, OpenRTB, Prebid Server, ads.txt and SCTE-35 — what each one does and where it sits in the request path.
What you can build against today with VAST, VMAP and OpenRTB, and exactly what to request to get the endpoint specification.
Shadow testing, a parallel run, cutover, and the rollback path — plus what to measure so you can tell whether it worked.
Whatever the integration, the same sequence runs on every ad break. Understanding it makes the rest of these pages easier to read.
Either the player requests ads directly, or your packaging layer detects a break marker in the stream and requests on the player's behalf. Break positions come from a VMAP document, from SCTE-35 markers in a live stream, or from your own schedule.
Direct-sold campaigns, house promotions and programmatic bids are collected together rather than offered in sequence. Programmatic demand arrives over OpenRTB, optionally via Prebid Server.
The break is filled as a pod, not slot by slot, so rules that span the break — competitive separation, frequency capping, sponsorship positions — can be enforced. Bids that arrive after the timeout are discarded.
Client-side integrations receive a VAST document and the player handles playback. Server-side integrations get the advertising written into the manifest, so the player sees one continuous stream — see server-side ad insertion.
Quartile and completion events are fired so buyers can verify delivery. In server-side integrations the server fires them on the player's behalf, which changes what you need to get right — see beaconing.
Gathering these first shortens every integration we have run. None of them require a contract to prepare.
| Item | Why it matters |
|---|---|
| Your delivery format | HLS or DASH, and whether you package in-house or use a third-party packager. This determines which integration paths are open to you. |
| Break signalling | How your content declares where ads go — a VMAP document, SCTE-35 markers, a fixed schedule, or player-side logic. |
| Device and app surface | Which platforms you ship on. Each has its own player constraints, and some restrict what a client-side integration can do. |
| Existing demand | Direct-sold campaigns, current programmatic partners, and any house or sponsorship inventory that must keep working. |
| Current baseline | Fill rate, CPM and latency as they stand today. Without these you cannot prove a migration helped — see what to measure. |
| Your ads.txt and app-ads.txt | Buyers filter unauthorised supply automatically, so a stale file suppresses demand before anything reaches the auction. |
The endpoint-level reference — base URL, authentication, request and response schemas, error codes and rate limits — is not on this site yet. We would rather publish nothing than publish a reference that does not match what the service actually accepts.
See the API and integration reference for what you can build against today, what the specification will define, and exactly what to send us to get it.
Every integration we run has a named solutions engineer from scoping through cutover. If you would rather talk it through than read it, book a technical walkthrough — it is run by an engineer, not a salesperson.
A 30-minute technical walkthrough covering decisioning, insertion and reporting — and what a shadow test would look like against your current setup.