What you can integrate against today

What is published, and what is not

Being direct about this, because your time is worth more than our marketing.

What you can build against today

The message formats are public specifications. If your player already speaks them, most of the integration surface is already familiar — only the destination and the credentials are ours.

A VAST response is a VAST response

For a client-side integration, the ad server returns a VAST document. That shape is defined by the IAB, not by us. Any player that handles VAST today will handle ours. Structurally, what comes back is:

<!-- IAB VAST structure — the public specification, not a GoGo-specific format -->
<VAST version="4.2">
  <Ad id="...">
    <InLine>
      <AdSystem>...</AdSystem>
      <Impression><!-- fired on first frame --></Impression>
      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:15</Duration>
            <TrackingEvents><!-- quartiles, complete --></TrackingEvents>
            <MediaFiles><!-- one per rendition --></MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

Work you can do now: confirm your player handles VAST wrappers without excessive latency, verify it fires all quartile events, and check its behaviour on an empty response. That last one matters more than teams expect — an unfilled avail is normal traffic, not an error, and a player that mishandles it shows a black frame.

Podded requests are OpenRTB 2.6

For programmatic demand, requests and responses follow OpenRTB. Version 2.6 is the one that matters for CTV because it carries pod structure, so a whole ad break is auctioned as a unit rather than slot by slot.

Work you can do now: establish how your inventory expresses pod duration and slot count, and whether break signalling reaches you as SCTE-35, as a VMAP document, or from your own schedule. This determines the integration path and is the first thing a solutions engineer will ask.

Server-side insertion changes what you prepare

In a server-side integration your app requests a manifest from the insertion layer rather than directly from your CDN origin. In practice that is a change to the playback URL your app constructs, and it is worth locating that code before the project starts.

Read what SSAI requires for the packaging-side prerequisites, and beaconing for the part that determines whether your impression counts will agree with your buyers'.

What the specification will define

So you can plan the work before you have the document. Every ad-serving API has to answer these, and ours is no exception:

• Ad decision request. How you identify the property, the content, the break position, pod duration and slot count, the device and app context, and the consent signals that apply.
• Response shape per integration. VAST for client-side; manifest handling for server-side.
• Authentication and key handling. How credentials are issued, scoped and rotated.
• Versioning policy. How a breaking change is signalled and how long the previous version keeps working. Ask about this explicitly — it is the difference between a stable integration and an annual surprise.
• Error semantics. Which failures are retryable and which are terminal. Critically, how "no ad available" is distinguished from "something broke", because your player must treat those differently.
• Timeouts and rate limits. The timeout is the tunable trade-off between admitting more demand and making a viewer wait — see where the 20 milliseconds go.
• Reporting access. How you pull per-impression auction traces and export your own data. See what you can actually see.
• Sandbox. Whether you get a non-production environment, and whether it returns representative demand or fixtures.

What to send us

Include these and the first reply can be the specification plus a scoped integration plan, rather than a discovery call.

1. Your delivery setup

   HLS or DASH; whether you package in-house or use a third-party packager; and which CDN serves your segments.

2. How breaks are signalled

   SCTE-35 markers, a VMAP document, a fixed schedule, or player-side logic. If you are not sure, say so — that is a common answer and it is diagnosable.

3. Your device and app surface

   Which platforms you ship on, and which player or SDK each one uses.

4. Live, on-demand, or both

   Live changes the signalling requirements and the concurrency profile substantially.

5. Existing demand

   Direct-sold campaigns, current programmatic partners, and any house or sponsorship inventory that must keep working through a change.

6. Rough monthly ad request volume

   An order of magnitude is enough. It determines the shape of the sandbox and the shadow test.

That list is deliberately the same as what you need before you start — gathering it once serves both purposes.

You do not need the API to evaluate us

Worth saying, because waiting on a document is a common reason evaluations stall. Two routes need no integration work from you at all:

• A shadow test. We mirror a slice of your live ad requests and show you what we would have decided, next to what your current ad server actually did. Nothing reaches a viewer.
• Demand-side participation. We bid into your existing ad server over OpenRTB or Prebid Server, so you find out whether we compete on your inventory before changing anything. See server-side bidding.

Next

• Standards reference — the formats above, in detail
• Integration paths — which model fits your stack
• Technical FAQ — the questions that come up before a first call