What Is a Postback URL? S2S Tracking Explained

What a postback URL is

A postback URL is an address on your server that another platform calls when a conversion happens. The call carries the details of that conversion, such as which user completed it, what it paid, and a unique transaction ID. Your server reads those details, records the conversion, and answers that it received it.

Because the call goes directly from one server to another, postback tracking is also called server-to-server tracking, S2S tracking, or server-side tracking. Offerwalls, affiliate networks, mobile measurement tools, and ad platforms all use it.

Postback vs tracking pixel

The older way to track a conversion is a pixel: a tiny image or script on the thank-you page that the user’s browser loads. A postback does not need the browser at all.

How postback tracking works, step by step

1. The click carries an ID. When a user opens an offer, the link includes your user ID or a click ID, for example ?user_id=4821.
2. The other side stores it. The network or advertiser keeps that ID with the click.
3. The user converts. They install the app, sign up, or finish the task.
4. The postback fires. The other server calls your postback URL and fills in the user ID, the payout, and a transaction ID.
5. Your server checks and credits. It verifies the request, credits the user once, and answers with HTTP 200.

A postback URL you enter in a dashboard usually looks like this:

https://example.com/postback?user={user_id}&amount={reward}&tx={transaction_id}&sig={hash}

When a conversion happens, every macro in curly brackets is replaced with a real value, so your server receives something like:

https://example.com/postback?user=4821&amount=150&tx=9f3a71c2&sig=5b1e...

Common postback macros

Every platform names its macros a little differently, but most offer the same kinds of values:

• User ID or sub ID: the ID you passed in the link, so you know whom to credit.
• Click ID: a unique ID for the click, used by affiliate networks and trackers.
• Transaction ID: a unique ID for the conversion. Use it to ignore duplicates.
• Payout: what you earn for the conversion, usually in USD.
• Reward: the amount in your own currency, such as coins or points, already converted.
• Offer ID and name: which offer was completed.
• Status: whether the call adds a reward or removes one after a chargeback.
• Country and IP: where the user was, useful for fraud checks.
• Signature or hash: proof that the call really came from the platform.

How to secure your postback URL

A postback URL is not a secret. Anyone who finds it can call it, so your script must never credit a reward just because a request arrived. Use these checks:

• Verify the signature. Most platforms sign each postback with a secret key only you and they know, usually with HMAC-SHA256. Recalculate the signature on your side and compare.
• Ignore duplicates. Store every transaction ID and skip any that you have already processed. Platforms retry calls, and a retry must never pay twice.
• Allow known IPs if the platform publishes the addresses it sends from.
• Use HTTPS so values cannot be read or changed on the way.
• Check the values. Reject unknown user IDs and amounts that make no sense.

A signature check in PHP can be as short as this:

$expected = hash_hmac('sha256', $_GET['tx'] . ':' . $_GET['user'] . ':' . $_GET['amount'], 'YOUR_SECRET_KEY');
if (!hash_equals($expected, $_GET['sig'] ?? '')) {
    http_response_code(403);
    exit;
}

The exact string that is signed differs between platforms, so always follow the documentation of the one you integrate.

Chargebacks and reversals

Some conversions are reversed later, for example when an advertiser finds fraud or a purchase is refunded. Platforms report this with a second postback, marked by a status value or a negative amount. Your script should remove the reward it gave for that transaction.

If the user has already spent or withdrawn the reward, their balance goes below zero. That is why many rewards sites hold new earnings for a while before they can be cashed out. Shark Earnings, our sister rewards site, publishes its hold time table so users know how long each kind of offer is held.

Responses, retries, and logs

• Answer fast with HTTP 200 once you have stored the conversion. Do slow work, such as sending emails, afterwards.
• Expect retries. Many platforms call again when they get an error or a timeout, which is another reason to ignore duplicate transaction IDs.
• Log every call with the time, the full query, and your answer. When a user says a reward is missing, the log shows at once whether the postback ever arrived.

Why postbacks go missing

When conversions do not appear, the cause is usually one of these:

1. Macros were not replaced. You see {user_id} literally in your log, which means the macro name is wrong for that platform.
2. A firewall blocked the call. Bot protection and security rules often block server requests. Allow your postback path or the platform’s IPs.
3. A redirect dropped the values. An http to https or www redirect can lose the query string. Enter the final address.
4. Your script returned an error, so the platform marked the postback as failed.
5. The user ID never reached the link, so the platform had nobody to report.
6. Signature mismatch because a value was URL-encoded differently than expected.

Some problems start on the user’s side, when ad blockers, VPNs, or strict privacy settings break the click before the conversion. Shark Earnings explains these in Why didn’t my offer track?, a guide written for users of a rewards site.

Postbacks on Sharklio

On Sharklio, every publisher app gets its own secret key and its own postback URL. The app page lists the available macros, including a status of 1 for a reward and 2 for a chargeback, and shows how to verify the hash with your secret key. A postback log in the dashboard lists each call and your server’s answer. Publisher accounts are opening soon. Read How the Sharklio offerwall works to see how the pieces fit together.

Frequently asked questions