Offerwall Integration: Iframe, Link or API?

How do you integrate an offerwall?

There are five common ways to integrate an offerwall: open a link in a new tab, embed it in an iframe on your website, load it in a WebView inside your app, open it in an in-app browser tab, or load offers through an API and show them in your own design. For most websites an iframe is the best balance of effort and experience. For mobile apps, open the link in a WebView or in-app browser tab. The API is for publishers who need full control of the design and are ready to build it.

Whichever you choose, two parts stay the same: your server signs the link or request for the signed-in user, and your server credits rewards from postbacks. How to show the wall and how to credit users are separate decisions. This guide covers the first one, and it is worth getting right: a wall that loads smoothly where your users already are gets opened more often, and that is revenue you earn from traffic you already have. For the second, see Postback security: verify every reward call.

Link, iframe, WebView, browser tab and API side by side

The foundation: a signed link built on your server

On Sharklio, the wall for each user is one URL:

https://wall.sharklio.com/{APP_ID}?user_id={USER_ID}&hash={HASH}

The user ID is the ID of the signed-in user in your system and must never change for the same person. The hash is an HMAC-SHA256 of that user ID with your app’s link hash salt, so nobody can edit the link to open the wall as someone else. The salt is a secret: build the link on your server and send only the finished URL to the browser or app. The Offerwall link docs have the code in PHP, Node.js, and Python, and the Integration tab has a Test a link tool that shows the exact link your server should produce.

There is no SDK. Every option below except the API is simply a different place to open this link. If you want to understand what an SDK would have added, read What is an SDK?

Option 1: a direct link in a new tab

The simplest integration is a button that opens the signed link in a new tab or window. It works everywhere, with no domain restrictions and no layout work, which makes it a good way to go live quickly or to serve a Discord server or newsletter.

There is nothing to embed or size, and it works on every device and browser. The cost is that users leave your page, and some never come back to see their balance update. Generate the link when the user clicks, or when the page loads for a signed-in user, and never cache one user’s link where another user could get it.

Option 2: embed the offerwall in an iframe

An iframe puts the wall inside your own page, under your header and navigation. The basic embed from the docs is:

<iframe title="Offerwall" src="https://wall.sharklio.com/{APP_ID}?user_id={USER_ID}&amp;hash={HASH}"
  width="100%" height="800" style="border:0" allow="clipboard-write"></iframe>

Three details decide whether it works well:

• It only loads on your registered website. For safety, the wall only loads inside frames on the website you registered for the app and its subdomains. Browsers enforce this with the frame-ancestors rule of Content Security Policy, which tells a browser which sites may embed a page. If the frame stays blank on a staging domain or a second site, that is why. Embed it on the registered domain or a subdomain, register the other site as its own app, or ask support to change the website.
• Give it space. Put the wall on its own page and give the frame enough height, so users do not get a scroll bar inside a scroll bar. Check it at phone width.
• Test in more than one browser. The wall runs on a different site from yours, so browsers treat what it stores as third-party. Safari blocks third-party cookies by default, and Firefox keeps them in a separate jar for each site. If an offer flow misbehaves only inside the frame, open the same link directly in the same browser to narrow it down.

Build the iframe URL on your server when you render the page, exactly like the direct link. Never put the salt in front-end JavaScript to build it in the browser.

Option 3: a WebView inside a mobile app

A WebView renders the wall inside your app’s own screen, so you keep your header, a close button, and your look. Iframe domain rules do not apply because the page is not framed by a website: the Sharklio link opened directly in a WebView works anywhere. The flow is always the same:

1. The app asks your backend for the wall link, using the user’s normal session.
2. Your backend builds the signed link and returns it.
3. The app loads that link in the WebView.

What to handle on Android and iOS:

• JavaScript. Android’s documentation notes that JavaScript is disabled in a WebView by default. The wall needs it, so enable it for this screen.
• Store and external links. Many offers send users to an app store page or another app. Android’s documentation shows how to intercept navigation with a WebViewClient and shouldOverrideUrlLoading(), and hand links you do not want inside the WebView to the system. Do the equivalent on iOS, and test a store link from a real offer before release.
• Back and close. Give users an obvious way out, and make the back button go back inside the wall before it closes the screen.
• Balance refresh. Rewards reach your server through postbacks, not through the page. Reload the user’s balance from your backend when the WebView closes.
• No bridges you do not need. Do not expose app functions to pages in the WebView. Android’s documentation warns that a JavaScript interface lets JavaScript control your app and should only be used with content you wrote.

Option 4: an in-app browser tab

Android Custom Tabs and iOS SFSafariViewController open a page in a browser view on top of your app. Google describes Custom Tabs as powered by the user’s preferred browser, sharing its cookie jar, saved passwords, and permissions. Apple’s WebKit team notes that user activity in SFSafariViewController is not visible to your app. The result is fewer edge cases with store redirects, sign-ins, and cookies, because they behave the way the user’s browser handles them.

The trade-off is less control: you cannot restyle the browser chrome or read what happens inside. That is fine for an offerwall, since everything your app needs arrives through postbacks. If your WebView keeps fighting store links, an in-app browser tab is often the quickest fix. Monetize a mobile game with an offerwall covers the game-side decisions.

Option 5: the API app type

When you create an app on Sharklio, you choose its type: Offerwall, a ready-made wall you open with one link or embed with one iframe, or API, where you load offers as data and show them in your own design. The choice cannot be changed once the app is live, so decide before you submit it. The API reference is not public yet; if you need the API type, say so in your application or contact [email protected].

With any offer API, the extra freedom comes with extra work. Before choosing it, make sure you can:

• Show each offer’s requirements accurately, so users know what counts as complete. Unclear instructions lead to rejections and support tickets.
• Keep the list fresh, so users do not start offers that have ended or changed.
• Show progress and results in your own interface, since the ready-made wall’s Reward status view is not there to do it for you.
• Keep secrets on the server, so any keys stay in your backend, never in a page or an app bundle.

If you are not sure, start with the Offerwall type. Its Design tab covers logo, currency icon, header image, colors, corner radius, card padding, and font size, which is enough for most brands to make the wall feel native. You can be live in an afternoon and spend your time on placement instead.

Which offerwall integration should you choose?

• A website with signed-in users: iframe on its own page, with a direct link as a fallback for other domains.
• A native mobile app or game: WebView if you want it inside your UI and can test store links, or an in-app browser tab for the least effort.
• A website and an app with the same users: one app with the same user ID on both. If they need different currencies, add a second app.
• A community such as Discord: a direct link built per member, for example by a bot command. See How to monetize a Discord server.
• A product with a strict design system: the API type, if you can take on the work above.

Where the entry point sits matters as much as the method. Read Offerwall placement: where to put it to earn more next.

Common integration mistakes

1. Building the hash in the browser or the app, which exposes the salt. Anyone with it can open the wall as any user.
2. Using a device ID as the user ID, so a reinstall creates a new user and earlier rewards cannot be matched.
3. Mixing up keys: the link hash salt signs the wall link, and the postback secret key verifies postbacks. They are different values.
4. Testing the iframe on a domain you did not register and assuming the wall is broken.
5. Crediting from the page instead of from postbacks.

The Testing and troubleshooting docs list the error pages you may see, such as Link not valid or Missing user ID, with the fix for each.

Frequently asked questions