Direct Offer Links: Share One Offer Instead of the Wall

What is a direct offer link on Sharklio?

A direct offer link opens one offer of your offerwall instead of the whole list. You copy it from the offer’s details on the Offers page of your dashboard, fill in the same user_id and hash as in your offerwall link, and send it to one user. The user lands on that offer, in your currency and your wall design, and when the advertiser confirms the result you get the usual signed postback.

Use it when you already know which offer fits a user, for example in an email to your members or a featured offer on your site. It is not a public share link: every direct link is signed for one user. If you are new to the wall itself, read how the Sharklio offerwall works first.

Where to find an offer link

1. In the sidebar of your dashboard, click Offers.
2. If you have more than one app, click the app’s name in the row at the top. Each app has its own links, because the link contains that app’s ID.
3. Click the offer’s name or image, or Details, to open its details.
4. Under Offer link, click Copy.

The details window also shows the offer’s ID (for example #58), steps, countries and devices. How to use the Offers page covers the rest of the page.

What you see under Offer link depends on the offer’s status for your app:

Some offers come in several versions, for example Android and iOS. One link covers them all and opens the version that fits the user’s device and country. Which offers can appear at all is covered in how to choose which offers your users see.

The URL format: user_id and hash

The copied link looks like this:

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

The hash is the one you already build for the offerwall link. The offer ID is not part of it, so one hash per user works for the wall and every offer. HMAC is defined in RFC 2104 (plain-English version: What is HMAC?): without your salt, nobody can make a valid link for another user ID.

Build the link on your server, the same way the Offerwall link docs show for the wall, and add the offer path:

$hash = hash_hmac('sha256', $userId, $linkHashSalt);
$url  = 'https://wall.sharklio.com/' . $appId . '/offer/' . $offerId
      . '?user_id=' . rawurlencode($userId) . '&hash=' . $hash;

The link hash salt stays on your server, never in JavaScript or an app bundle. See how to keep your app secrets safe.

When a direct link beats the full wall

The full wall shows every offer that fits the user’s country and device, so it is the right default. A direct link is better when you have a reason to put one offer in front of one person:

For bots, Telegram’s Bot API reference describes the inline keyboard button’s url field as an HTTP or tg:// URL opened when the button is pressed, which suits a signed link sent in a private chat. For Discord, see how to add an offerwall to a Discord bot.

An email promoting an offer is commercial email. The FTC’s CAN-SPAM Act compliance guide says the law covers email to existing customers too, and lists the basics: accurate headers and subject lines, a valid physical postal address, a clear way to opt out, and opt-outs honored within 10 business days (checked on October 29, 2026). Sharklio’s Terms also forbid promoting the offerwall or offer links with spam, including unsolicited email, SMS or messages.

Describe the offer the way its details do: the Terms do not allow promotion that misdescribes what a user must do to earn a reward.

Why signed links must never be posted publicly

A signed link is that user’s identity on your wall. Whoever opens it is treated as that user ID, and every reward they earn goes to that one account. Posting it in a channel, a group or a comment hands that identity to everyone who sees it.

The wall also watches how each user ID is used. When one user ID opens offers from another country within 24 hours, offers pause for that user for a day (the user sees “Location changed”). When it shows up on many different internet providers in a short time, the wall blocks that user ID on your app and reverses the credits already confirmed for it, which reaches your server as status 2 postbacks. A public link shared with dozens of people looks exactly like that.

URLs also leak: OWASP’s page on information exposure through query strings lists browser history, the cache, web logs and the Referer header, and notes that HTTPS alone does not prevent it. Build links when they are used, and do not store them.

If you want to promote an offer to a public audience, post a link to a page on your own site that requires sign-in, and let your server build the direct link from there. Affiliate marketing on Telegram explains how public affiliate links differ from a per-user offerwall link, and Stop multi-accounting and VPN abuse covers the abuse side.

What the user sees when the link opens

The direct link goes through the same checks as your offerwall: a valid user ID and hash, a live app, and a normal connection (VPN, proxy, Tor and data center users get a block page). Then:

• The offer runs for this user: they see the offer page in your wall design, with the steps and rewards in your currency, the time left to finish, and a start button. The page says to open the offer with that button, or the steps cannot be tracked.
• Another version fits better: the link opens the version for the user’s device and country, unless they already started a version of the same offer.
• They already started it: they see their progress on it, or a read-only page if it is finished.
• The offer does not run for them: they see “Offer not available” with “This offer has expired, or it is not available in your country.”

The close button takes the user to your full offerwall, so one offer can still lead to others.

How the conversion is tracked and credited

1. Click. Opening the offer page records a click for that user and offer, with the country, device and any sub IDs.
2. Start. The start button sends the user to the advertiser through that tracked click.
3. Confirmation. The advertiser confirms each step from their server, and each step is credited on its own.
4. Postback. Your postback URL gets status 1 with the user ID, transaction ID, reward and hash, exactly as from the wall. {offer_id} carries the offer, and {integration} is offerwall.
5. Reversal. If the result is taken back later, you get status 2 with the same transaction ID.

Credit users only from that signed postback, never from the click or from the user saying they finished. What is a postback URL? explains the mechanism, and the Postbacks docs list every macro and the verification code.

To see what one email or banner earned, add a sub ID such as &sub1=email_oct to the link. It comes back in every postback of that transaction as {sub1}, and your reports can group results by sub ID. Click IDs and sub IDs explains the idea, and How to read your dashboard and reports shows where the numbers appear.

How to test a direct offer link

1. Check the link. In your app, open the Integration tab, then Integration status, then Check a link. Paste a direct link your server built. The check recognizes it (“This link opens one offer.”) and runs the same checks as for the wall link, including the hash.
2. Compare with Test a link. In the same window, type the user ID into Test a link. It shows the wall link your server should build. The user_id and hash must match the ones in your direct link exactly.
3. Open it as a real user. Use a real user ID from your own site, from a normal home or mobile connection, in a country and on a device the offer runs on. The test user owner-test can look around the wall but cannot start offers.
4. Test crediting with a test postback. Use Send a test postback in Integration status. Test transaction IDs start with test_, and every attempt is listed under Reports, Postbacks.

Do not complete offers yourself for revenue; the Terms forbid it. The full pre-launch routine is in How to test your app before it goes live, and the error pages are listed in the Testing docs.

Frequently asked questions