Multiple Apps in One Publisher Account: How It Works

Can one publisher account run multiple apps?

Yes. One Sharklio publisher account can hold up to 5 apps, and our team can raise the limit if you need more. Each app is one place where you show offers, with its own currency, design, keys and postback, while your login, payout method and Payments page stay shared. Your publisher application is reviewed once, so every app you add after approval goes live right away.

The bigger question is whether you need a second app at all. Often you do not: one app can serve a website, a mobile app and a Discord bot at the same time, as long as they share one currency and one user balance.

One app or several: how to decide

Every Sharklio app comes with all three integrations at once: the offerwall (as a link, an iframe or a floating button), the Offers API, and the mobile SDK for Android, iOS, Flutter, React Native and Unity. They all share the app’s App ID, keys and postback. So a single app can already show offers on your website, inside your Android app and in Discord messages, because the offerwall link works anywhere, with no website restriction.

Only embedding is tied to one website. The wall tells browsers which pages may frame it with the Content Security Policy frame-ancestors directive, which MDN describes as the list of valid parents that may embed a page. For your app, it allows the https website you registered and its subdomains, so a page on any other domain cannot show the wall in a frame.

Add a second app when a property needs something one app cannot give it twice:

A second app for the same audience, only so the same people can do the same offers again, is not allowed. The Terms of Service say you must not create several properties to reuse the same traffic (checked on October 29, 2026), and Traffic quality rules explains what that means in practice. A genuinely different setup, such as a separate website or a community with its own currency, is fine.

What each app has for itself, and what the account shares

Because the currency is per app, a website can pay in Coins at one rate while your Discord community pays in Shells at another. How to choose each rate is in How to set your virtual currency exchange rate, and the design options are in How to customize your offerwall design.

How to add a second app

1. In the sidebar under Publish, click Apps, then New app at the top right.
2. On Add a new app, fill in App name and Website or app URL under General. Use the address where this property really lives, because embedding only works on that domain and its subdomains, and the address cannot be changed later.
3. Under Currency, set the currency name, conversion rate, split and rounding for this property, then click Create app.
4. The app opens on its Postback tab. Add the postback URL for this property, then set up the Design tab and take the link, code and keys from Integration.

Every field is explained in How to create your first app. When you reach your limit, the New app button turns gray and the Apps page says “You have reached your limit of 5 apps.” Email partners@sharklio.com if you need more.

Example: a website, an Android app and a Discord community

Illustrative example, with made-up names. A publisher runs a puzzle game on the web and on Android, with one account system and one balance of Gems. It also runs a Discord community where members earn Shells, a bot currency that has nothing to do with game accounts.

The website and the Android app stay in one app, because a player who starts an offer on the phone should see it as already done on the website, and both feed one Gems balance. The Discord community gets its own app because it has its own currency and its own server. If most of your Discord members are the same people as your players, consider linking Discord to game accounts and paying Gems through App 1 instead. Add an offerwall to a Discord bot covers the bot side.

Can apps share one user ID space?

You can use the same kind of user ID everywhere, for example the IDs from your own database. Each app’s users are kept apart, though: the offers a user already did, the offers that are still open, and the Active users count are all tracked per app. User 1234 in App 1 and user 1234 in App 2 are two different users to us.

That has two consequences:

• One person, one app. If the same person could reach the same offers through two apps, they could complete them twice, which is exactly the reuse of traffic the Terms forbid. If two properties share users and a balance, put them in one app.
• Active users add up per app. A person who opens the wall in two apps counts once in each.

Each user ID must be unique and never change for that user, up to 100 characters, using letters, numbers and . _ @ : + -. Use a random or database ID, not an email address.

How to keep crediting separate

Every app signs its traffic with its own secrets. The link hash salt makes the {HASH} in that app’s offerwall links, the postback secret key signs that app’s postbacks, and the API key works only for that app’s Offers API, SDK sessions and Reporting API. Both hashes are HMAC-SHA256, the keyed-hash method described in RFC 2104, so a salt or key from one app never validates anything from another.

The postback carries no app macro, so your server has to know which app a postback belongs to before it can check the hash. The simple way is a different postback URL per app:

App 1: https://api.example.com/sharklio/game?tx={transaction_id}&user={user_id}&amount={reward}&status={status}&hash={hash}&src={sub1}
App 2: https://bot.example.com/sharklio/discord?tx={transaction_id}&user={user_id}&amount={reward}&status={status}&hash={hash}

• Each endpoint verifies the hash with its own app’s postback secret key and credits its own currency.
• If one server receives both, use a fixed path or parameter per app (such as /sharklio/game and /sharklio/discord), look up the matching key, and store the app together with {transaction_id} so a credit is never applied twice. Prevent duplicate reward credits shows the pattern.
• Reversals come to the same app’s URL with the same {transaction_id} and status 2, so the right ledger takes the reward back.

Keeping keys per app also limits the damage if one leaks. The OWASP Secrets Management Cheat Sheet warns that when services share the same secrets, finding the source of a leak becomes hard. If one app’s key is exposed, you replace only that app’s key, as shown in How to rotate your keys and link salt, and the other apps keep working.

How to compare apps in your reports

Once you have two or more apps, the dashboard adds app controls everywhere:

• Apps page: every app with Total earnings, Earnings (30 days) and Active users (30 days). Click a column heading to sort by it. Each row also shows the app’s postback status and last conversion.
• Dashboard: an All apps menu next to the date menu narrows every number to one app.
• Performance: the Apps tab groups clicks, conversions, earnings, EPC, conversion rate and reversals by app, side by side. Click an app’s name to open its conversions. The All apps menu limits the other views, such as Countries or Sub IDs, to one app.
• Conversions, Chargebacks and Postbacks: an App column and an App filter. Export CSV includes the app name on every row.
• Reporting API: each API key only returns data of its own app, so to pull all apps into your own tools, call it once with each app’s key. See the Reporting API docs and Reporting API quick start.

When you compare, look at earnings per active user and conversion rate rather than total earnings alone, since a larger property will always earn more in total. How to read your dashboard and reports explains each number, and Why country and device mix changes earnings explains why two similar apps can earn very differently.

Hiding offers per app

The Offers page shows one app at a time. With more than one app, a row of app names appears at the top; click one to see and manage its offers. Hide and Show apply only to the selected app, so an offer can stay visible on your website and be hidden in your Discord community. A hidden offer disappears from that app’s offerwall, Offers API and SDK. See How to use the Offers page for the filters and bulk actions.

Deleting an app

You can delete an app until its first user starts an offer on it. Open the app, go to the General tab, and click Delete app in the Delete app box, then confirm. Deleting cannot be undone, and it frees a place under your app limit.

As soon as any user has started an offer in the app, or it has earned anything, the Delete app box is gone. The app stays so your reports and payouts stay complete. To close it, email partners@sharklio.com. Opening the wall with Open as a test user does not count, because the test user owner-test can look around but cannot start offers. Do not try real offers yourself to test an app: completing offers on your own properties is not allowed. Use Send a test postback in Integration status instead; test transaction IDs start with test_, so your server can ignore them.

Frequently asked questions