This is usually the wrong comparison: an API can supply catalogue records or launch URLs while an iframe displays the game. Slots Launch explicitly describes its API as a synchronisation interface rather than a live source for every page load, and its documentation requires use of its iframe URLs rather than extraction of final game endpoints. (docs.slotslaunch.com)
Which implementation approach fits which operating model?
The trade-offs below are implementation assessments, to be validated in a pilot.
| Approach | Appropriate use | Buyer-owned work | Key acceptance question |
|---|---|---|---|
| Manual authorised iframe | A small, stable set of review pages | Maintain placement, domain registration and removals | Can editors reliably identify and replace withdrawn content? |
| Catalogue API plus hosted iframe | Larger, changing catalogues | Synchronisation, ID mapping, signing and exception handling | Can catalogue updates continue without making visitor pages depend on live catalogue calls? |
| Supplier WordPress plugin | A WordPress-led editorial operation | Plugin lifecycle, cache compatibility, permissions and rollback | Does it operate correctly with the actual theme, cache and consent configuration? |
| Self-hosted compiled game | A suitably licensed original-game experience | Hosting, updates, dependencies and observability | What remains dependent on the vendor despite local files? |
| External play link | An approved off-site experience or fallback | Destination checks and clear visitor messaging | Is external linking permitted and supported for that endpoint? |
External links are not a universal fallback. First Look Games says its DGS links must be embedded on registered properties and direct visits are blocked. By contrast, Playin publishes external-link examples. Follow the relevant supplier’s supported method. (firstlookgames.com)
Why does a working wrapper page not prove the game loaded?
An iframe load event is not a game-ready event. MDN documents that iframe load can fire even when the embedded content fails to load. A monitoring check that records only this event can therefore misclassify failure as success. (developer.mozilla.org)
The parent page also has limited access to a cross-origin frame’s internals. Use supplier-supported events where available; postMessage can provide cross-origin communication, but receivers should validate the sender’s origin, source and message structure. (developer.mozilla.org)
Request separate signals for:
- Visitor requests launch.
- Launch authorisation succeeds or fails.
- Game becomes interactable.
- First interaction completes, where measurement is permitted.
- Session fails, closes or becomes unavailable.
These are proposed event requirements, not features verified across the compared suppliers. If no reliable game-ready signal exists, record readiness through a permitted test procedure and label the measurement limitation.
What commonly needs investigation on mobile Safari?
Investigate storage, framing policy and the launch flow independently. WebKit documents default third-party cookie blocking and mechanisms for permitted storage access. An embedded product that depends on cross-site cookies therefore needs specific testing; this does not mean every game will fail. (webkit.org)
The supplier’s frame-ancestors policy controls which parents may embed a document, whereas the parent’s frame-src policy controls allowed frame sources. Check the actual policy failure before changing headers, and do not weaken security controls simply to make an unsupported embed load. (developer.mozilla.org)
Detailed cross-origin resource timing also depends on the applicable timing permissions. Resource Timing data is not a substitute for an application-level readiness signal. (w3.org)