Integration Status in Sharklio, Explained Row by Row

What does Integration status show in Sharklio?

Integration status is the box at the top of your app’s Integration tab. It has one row per part of your setup: Offerwall link, Users reached your offerwall, Postback, and, once you use them, Offers API and Mobile SDK. Each row is done, needs attention, or not checked yet, and the badge next to the heading sums them up as All set, Needs attention, or a count such as 2 of 3 done. Buttons on the rows run the tests right away: Check a link, Open as a test user, and Send a test postback.

Labels below were checked against the dashboard on November 2, 2026. For the full test routine before launch, read How to test your app before it goes live.

Where to find it and how to read it

Open Apps and click Manage next to your app. Live apps open on the Integration tab, and only live apps have it. As the box itself says, “We never visit your site, so login-only pages are fine.” Every check works on what reaches Sharklio: links you paste, visits to your wall, requests from your server, and your server’s answers to postbacks.

• Icons. A check mark means done, an alert sign means needs attention, a clock means not checked yet.
• Which rows count. The first three always count. Offers API and Mobile SDK show only under their tab of How will you show the offers? until your server uses them; after that they always show and count.
• Refresh. After Open as a test user, the rows update when you come back to the dashboard tab.

The Postback bar above the stats, with its Working, Failing, Not set up, or No postbacks yet badge, uses the same health check as the Postback row. To see how the integrations differ, read Sharklio integration options: link, iframe, API and SDKs.

Every status at a glance

Times and numbers are examples. Your dashboard fills in your own.

The Offerwall link row and Check a link

This row needs attention only when three things are true: in the last 7 days visits failed with a wrong or missing hash or without a valid user ID; no users came, or at least one visit failed for every 20 users; and no link check has passed since the last failure. A few failures next to steady traffic, such as an old bookmark, stay a note in the Users row. The signature has no row of its own: a bad hash shows up here, and Check a link tells you why.

Click Check a link, paste a full link your site made for a real signed-in user, and click Check link. It is checked like the offerwall checks it and not saved. The result starts with a summary such as “One problem found. Fix it, then check the link again.” The messages you will meet most:

For “hash does not match this user ID.”, the checker tests the usual mistakes and names the one it finds, for example “You used the postback secret key. Use the link hash salt instead.”, the API key, a hashed URL-encoded ID, the salt and user ID swapped, plain SHA-256, another HMAC algorithm, your other app’s salt, Base64 instead of 64 hex characters, or other letter case. HMAC, described in RFC 2104, mixes a secret key into the hash; Sharklio uses the link hash salt as the key and the user ID as the message, so swapping them changes the result. You also get the Expected hash for this user ID and the Expected link, each with Copy. If nothing matches, think of an old salt after New link hash salt or a hash made for another user ID. The offerwall link docs have the code.

Test a link, in the same window, shows the exact link for any user ID. Opening it counts as a visit by that user, so use a test account.

The Users reached your offerwall row

This row counts the different user IDs that opened your wall in the last 7 days, today included, leaving out previews and the test user owner-test. Open as a test user opens your wall in a new tab as owner-test, with the hash filled in when the check is on, and is not counted as a user.

Once users open offers, a grey note splits them by integration, for example “Users who opened an offer, by integration: Offerwall 40, Floating button 12.” The floating button tags its own visits, plain links and iframes count as Offerwall, and adding via=link counts direct links apart. If the button does not show at all, see how to add a floating Earn button.

A red note lists the visits that failed in the last 7 days, with the time of the last one. Each reason matches a page your user saw:

• with a wrong or missing hash: Link not valid. Use Check a link.
• without a valid user ID: Missing user ID. Use Check a link.
• with an SDK session that is not valid: Session not valid.
• with an SDK session already used or expired: Session ended.

A grey note may count visits from blocked users: user IDs blocked on our side, who see Not available. Nothing to fix in your code. If Open as a test user shows VPN detected or Network not supported, no test visit is recorded; VPN or proxy detected on an offerwall explains why.

The Postback row

The row judges real postbacks. Test postbacks decide it only until the first real one, then show as a note such as “Last test postback OK, 5 mins ago.” when newer. A postback is accepted when your server answers with a 2xx code within 6 seconds; RFC 9110 defines 2xx as received, understood, and accepted. We do not follow redirects, so a 3xx counts as a failure.

The warning shows when the newest real postback failed, or when more postbacks failed than were delivered in the last 24 hours, retries included. That second rule can keep the warning up after your fix. The Postback tab words it plainly: “Most postbacks of the last 24 hours failed, so some users may be missing their rewards.” Click View failed postbacks, fix your endpoint, and send the missed ones again as How to resend a failed postback explains. For the hash check, read Postback security.

The Offers API and Mobile SDK rows

Offers API. Done once a request with your API key reaches us, plus how many users opened an offer from your start_url links in 7 days. Mobile SDK session requests use the same key and count too; Reporting API calls do not. A wrong key never counts, so if the row stays on No requests yet, read the error your server gets, such as invalid_api_key, in the Offers API errors. See also Build your own offerwall with an Offers API.

Mobile SDK. Each open needs a fresh session, valid once and for 10 minutes. Sessions made but never opened mean your app does not pass the token to Sharklio.open(), passes another value, or opens it too late. “Sessions failed” with no session ever made usually means the App ID in your app and the API key on your server belong to different apps. If sessions stop, the row keeps its check mark and says “Last session” with a date, so compare it with your traffic. The Android SDK troubleshooting table and How to add an offerwall to an Android app cover the setup.

How to re-test after a fix

1. Link. Deploy, make a fresh link for a real user, and paste it into Check a link. A pass sets the row to “Your last link check passed, just now.” unless enough new failures arrive. Open the link from a normal connection too.
2. Users. Old failures stay in the red note for 7 days. If the “Last one” time stops moving, the fix holds.
3. Postback. Send Credited (1), then Reversed (2), about 10 seconds apart. The Test postback result window shows the response code, answer time, the request we sent, and your server’s exact answer. Then resend failed real ones from Reports, Postbacks.
4. SDK or API. Create a session and open it at once in a debug build, or call the Offers API for a test user. The row shows the new time.

The Testing and troubleshooting docs list common problems, and the Postbacks page explains retries.

Frequently asked questions