DEMO SUPPLY / THE PUBLISHER’S RESEARCH DESKPERMISSION · COVERAGE · DELIVERY
Demo SupplySourcing research for US-facing publishers
Scope a shortlist

07Video and podcast roundups

What must buyers check against current documentation rather than a recording?

Use recordings to learn the questions; use current documents to implement the answers. The following findings are supporting reading, not additional video recommendations.

Is an older Slots Launch integration example still suitable?

Slots Launch’s API documentation states that signed iframe and API requests become required on 15 November 2026, with an exception where legacy mode is enabled. As of this report’s 27 October 2026 research date, that deadline is still in the future; confirm the applicable migration arrangements with the supplier. (docs.slotslaunch.com)

Its direct-embed documentation says signing secrets belong on the server and warns against caching signed URLs beyond their lifetime. It also distinguishes production signing from simply pasting a preview link into production HTML. These are reasons to verify implementation details against the documentation rather than reuse an old snippet unchanged. (docs.slotslaunch.com)

Is the catalogue API also the visitor-facing launch mechanism?

Not necessarily. Slots Launch explicitly describes its API as a synchronisation interface: import records, store them locally and retrieve updates periodically, rather than using the catalogue API as a live source for every visitor page load. That is a product-specific example, not a universal architecture rule. (docs.slotslaunch.com)

For a demo slot API versus iframe integration comparison, ask separately about catalogue synchronisation, launch authorisation, game delivery and support. Do not collapse those functions into a single “API available” checkbox.

How should game-ready timing be specified?

MDN documents restrictions on direct interaction between cross-origin documents and describes postMessage() as a mechanism for controlled communication between windows. A publisher should therefore agree an observable readiness condition with the supplier rather than assume it can inspect all internal game state. (developer.mozilla.org)

Our recommended measurement brief separates:

  • Publisher page readiness.
  • The visitor’s launch action.
  • The agreed playable state, if observable.
  • Failure, denial or timeout.

If no reliable playable-state signal exists, label the measurement limitation. Do not silently substitute page-load time for game-ready time.

Sources cited on this page

  1. docs.slotslaunch.comdocs.slotslaunch.com
  2. docs.slotslaunch.comdocs.slotslaunch.com
  3. developer.mozilla.orgdeveloper.mozilla.org