Interview objective: Obtain an architecture diagram that separates catalogue synchronisation from visitor-facing game delivery.
Put this to: The supplier’s integration engineer and the buyer’s engineering lead.
Why it matters to buyers: Slots Launch explicitly documents its API as a synchronisation service, not a live data source for every visitor page load. It recommends storing catalogue records locally and retrieving changes periodically; it warns that inappropriate live use may lead to throttling or suspension. (docs.slotslaunch.com)
Draft framing — a good answer should cover:
- What the API returns: metadata, launch instructions, assets or some combination.
- Which component hosts and serves the game itself.
- How identifiers, updates, withdrawals and deleted records reach the publisher’s database.
- Where authentication, signing, secrets and domain registration belong.
- What remains operational during a catalogue API outage versus a game-delivery outage.
- Which implementation tasks belong to the supplier and which remain with the publisher.
Sharp follow-up: “Walk through a normal page request without calling the catalogue API. Then show what happens when an existing game is withdrawn.”
Buyer output: An integration-responsibility diagram, request-volume assumptions and a failure-handling specification.
Do not frame API and iframe as necessarily competing products: ask whether the proposed implementation needs both, and what commercial and technical obligations attach to each.
Expert quote — awaiting interview: [Approved quotation and attribution.]