An iframe integration displays a hosted puzzle experience inside another webpage. A custom API integration uses backend requests and your own application logic to control more of the experience. The right choice depends on which responsibilities you want to own: identity, rendering, session orchestration, payments and rewards.
What an iframe does well
An iframe gives the hosted game its own document and execution context. Your application can present the surrounding experience without reproducing every game interaction. That is useful when a small team wants to test a campaign without building and maintaining a separate puzzle interface.
It is not automatically secure just because it is embedded. Review the iframe's permissions, the domains you trust and any messages exchanged with the parent page. Test the dimensions and scrolling on the devices your visitors use.
What an API changes
API access lets your backend coordinate supported actions, but an API endpoint is not the same as a complete game UI. Read the current contract for the specific mode, including authentication, identifiers, expiry, errors and result handling.
Bounty Puzzle separates some account-level API operations from Host-plan operations. Confirm the current requirements in your dashboard and documentation before implementation. Do not assume every endpoint is included because one authenticated request works.
| Decision | Hosted iframe | Custom integration |
|---|---|---|
| Game rendering | Hosted game | Depends on your implementation |
| Surrounding page | Your application | Your application |
| Integration effort | Usually less UI ownership | More coordination and maintenance |
| Backend identity | Still your responsibility when used | Your responsibility |
| Failure handling | Required for loading and sessions | Required across all owned components |
Keep credentials on the backend
Never place a privileged API key in an iframe URL, public page source or browser bundle. Browser code is accessible to visitors. Where an operation requires a secret, have your backend authenticate it and give the browser only the limited information it needs.
For cross-window messages, check both the expected origin and the payload structure. Avoid using a wildcard target origin for sensitive information. MDN's postMessage reference explains the browser mechanics and their security implications.
Make failure states part of the design
Handle missing campaigns, expired sessions, denied access and network interruptions visibly. A blank game frame is not an explanation. Tell the visitor whether they can retry or must contact the host.
For results that trigger rewards, implement idempotency in your backend. Save a stable session/result identifier and ensure replayed or retried events cannot grant the same reward twice.
Choose a small implementation milestone
Start with one mode and one successful end-to-end session: load, activate if needed, play, finish and process the outcome. Then test negative paths before adding more modes. The examples show the product interactions; the API docs describe supported integration paths.
Can we use an iframe and API together?
Yes, where the mode supports it. The iframe can handle play while your backend coordinates identity, activation and downstream outcomes using supported requests.
Is custom hosting always cheaper?
No. Compare infrastructure with engineering, operational support and ongoing maintenance. A lower hosting bill does not necessarily mean a lower total cost.
Sources and further reading
Build something people want to play.
Explore a working example, review the integration docs, or start your first campaign.
