Bring programmatic demand to your screens

Your screen opens our player URL and plays whatever the next slot returns. Pair it by scanning the QR code on your screen page, or by reading the six-digit code the screen puts on itself and entering it there. Nothing to install, no SDK and no credentials to exchange. The same URL works two ways: as the screen's own full-screen browser page, or pasted into a web-page widget inside the CMS you already schedule in, so an owner on Xibo, Yodeck or ScreenCloud never has to leave it. The widget route also takes an optional ?slots=N parameter, so a playlist item can ask for a fixed number of slots (?slots=1 for a single spot) instead of polling forever: once N slots have played the player stops requesting new ads and leaves the last creative on screen, which is what makes it behave as one discrete spot in your loop rather than a continuously polling player.

Before you commit inventory: Test the widget route on your own hardware before you commit inventory to it. We have tested a plain browser iframe, not any specific CMS product, and two separate faults look the same from your dashboard: some older Android players save a still snapshot of a web page instead of keeping it live, and some Samsung Tizen panels paint an embedded HTML ad solid black. Working looks like this. Stand in front of the screen, watch the creative change on its own within a slot or two, and check that the impressions on your screen page climb while you watch. A frozen image, or a black rectangle that still reports impressions, means the widget is not rendering live and the screen's own browser page is the route to use instead.

Your player calls a per-screen tag URL and gets a VAST document back, exactly as it would call any video ad server. The screen identifier can arrive as a path segment or as a query parameter, and the parameter names, screen lookup and VAST version are configurable per supplier. We relay the buyer's own VAST document and add a single impression beacon, so their trackers stay intact.

Your CMS asks us for the next slot over HTTP and gets back a small JSON object: kind, slot_token, media_url or html, mime, duration_ms, w, h and trackers. A kind of idle means the slot is yours to fill. Parameters can arrive in the query string or in a JSON body, and every payload key can be renamed to match what your CMS already expects.

Your SSP posts an OpenRTB 2.6 DOOH bid request to our /rtb/bid endpoint with your key as a bearer token, and reads a standard bid response. Win and billing notices are rewritten through us, so nurl and burl point at single-use Eskimi URLs that relay to the buyer once the play is confirmed.