What Is a Postback URL? Server-to-Server Conversion Tracking Explained

A postback URL is a link the affiliate network calls on your server when a conversion happens — a sale, a signup, a lead — instead of relying on a snippet running in the buyer's browser. It's a plain server-to-server HTTP request, so it works with no cookies, no JavaScript, and no dependence on where the user finally converts. If you run affiliate offers and you're tired of losing conversions to blocked pixels and expired cookies, the postback URL is the mechanism that fixes it.

Quick answer

A postback URL (also called a server-to-server or S2S postback) is a callback the affiliate network fires to your tracking system when a conversion is confirmed. On each redirect, ShortlyLink appends a click id (cid), an expiry (exp), and an HMAC-SHA256 signature (sig) to your destination URL. The network stores that click id and, when the user converts, calls your postback with the id plus an amount and a status. ShortlyLink validates the signature (24-hour TTL, timing-safe), dedupes by click id (a repeat returns HTTP 409), clamps the payout, and normalizes the status to confirmed, pending, or rejected. No browser and no cookies are involved — which is exactly why it's more reliable than a pixel.

What is a postback URL, exactly?

Think of a postback as a phone call between two servers. The user clicks your affiliate link, lands on the merchant's site, and does whatever they came to do. When that conversion registers in the network's system, the network's server makes a direct HTTP request to your server — the postback — announcing "click X just converted for $Y with status Z." Your server records it. The user's browser never touches this exchange.

That's the defining trait: a postback is machine-to-machine. Contrast it with a tracking pixel, which is a 1x1 image or a script that must load inside the user's browser on a thank-you page. Pixels depend on the browser executing them, on the user reaching the right page, and historically on cookies surviving the round trip. Postbacks depend on none of that. The network already knows the conversion happened; it just tells your server directly.

For affiliate marketers, this matters because your conversions and payouts drive every optimization decision you make. If tracking silently drops 15% of conversions because of ad blockers or Safari's cookie restrictions, you're bidding, scaling, and killing campaigns on bad numbers. Server-to-server tracking removes the browser as a point of failure.

How the click-id round trip works in ShortlyLink

The whole system hinges on one identifier travelling out and coming back. Here's the round trip, step by step.

1. The click. Someone clicks your ShortlyLink short link. ShortlyLink resolves the destination and issues an HTTP 302 redirect to the merchant.

2. The append. On that redirect, ShortlyLink attaches three values to your destination URL:

• cid — the click id, a unique identifier for this exact click.
• exp — an expiry timestamp that sets how long the click stays valid for conversion.
• sig — an HMAC-SHA256 signature over those values, so the postback can be trusted as genuine and untampered.

3. The handoff. The merchant's landing page receives those parameters. The affiliate network stores the click id against the visitor's session — this is the network's job, and every serious network supports storing and returning a passed-in click id (often called subid, aff_sub, s2, or clickid in their docs).

4. The conversion. The user buys. The network finalizes the conversion on its side.

5. The postback. The network fires your postback URL, passing back the same click id along with the payout amount and a status. This is the return leg of the trip — the id you sent out comes home.

6. The validation and record. ShortlyLink receives the postback at GET /postback, runs it through the checks below, and — if it passes — records a conversion with revenue attached to the original click and link.

Because the click id ties the conversion back to a specific click, you keep full attribution: which link, which campaign, which country, which device, which A/B variant. The conversion isn't a floating number on a dashboard; it's stitched to the click that earned it.

What ShortlyLink validates on every postback

A postback endpoint that accepts anything is a liability — anyone who guesses the URL could inject fake conversions. ShortlyLink runs each incoming postback through a signed, deduplicated path before it counts:

• Signature check (timing-safe). ShortlyLink recomputes the HMAC and compares it using a timing-safe comparison, so the endpoint can't be probed via timing attacks. A bad or missing signature is rejected.
• 24-hour TTL. The signature is valid for 24 hours. Conversions that arrive after the window are rejected as stale. If your offers have a long confirmation lag, account for this — the click's signature dies after a day.
• Dedupe by click id. Each click id can convert once. A repeat postback for the same id returns HTTP 409 Conflict, so a network that retries (or a double-fire) never double-counts your revenue.
• Payout clamping. The reported amount is capped at the link's maxPayout, or a default max of 1000 if you didn't set one. Negative, NaN, or Infinity amounts are coerced to 0. This protects your reporting from malformed or malicious payout values.
• Status normalization. Whatever the network sends is normalized to one of three states — confirmed, pending, or rejected. An unrecognized status defaults to confirmed.

The same signed path also backs the browser pixel option (POST /api/conversions/pixel), so whichever input you use, the validation is consistent. Set your maxPayout per link up front so the clamp works in your favor rather than surprising you later.

What a postback URL looks like

You configure the postback URL inside your affiliate network's dashboard, using the network's placeholder tokens so it substitutes real values at fire time. The shape looks like this:

https://go.shortlylink.com/postback?cid={CLICK_ID}&exp={EXP}&sig={SIG}&amount={PAYOUT}&status={STATUS}

The {...} tokens are placeholders — every network names them differently, so check your network's macro reference. The cid, exp, and sig values are the ones ShortlyLink handed the network on the outbound click, echoed back unchanged. amount and status are supplied by the network at conversion time.

A concrete request the network might fire could resolve to:

https://go.shortlylink.com/postback?cid=a1b2c3d4e5f6g7h8&exp=1753900000&sig=9f86d081884c7d65&amount=42.50&status=confirmed

That single GET request is the entire conversion. No page load, no script, no cookie.

Postback vs pixel tracking: which should you use?

Both are valid, and ShortlyLink supports both through the same signed, deduped path. The choice comes down to reliability versus setup simplicity.

	Postback URL (server-to-server)	Pixel (browser)
Where it runs	Network's server → your server	Merchant's thank-you page in the user's browser
Cookies required	No	Historically yes; increasingly restricted
Blocked by ad blockers	No	Sometimes
Setup	Paste a URL into the network dashboard	Drop a snippet on the confirmation page
Needs thank-you-page access	No	Yes
Reliability	Higher — no browser dependency	Lower — depends on page load and browser
ShortlyLink endpoint	GET /postback	POST /api/conversions/pixel

Use a postback whenever the network supports it — which most do. It's cookie-independent, survives ad blockers and browser privacy changes, and doesn't need you to touch the merchant's confirmation page. Use a pixel when you can't configure a postback but you can place a snippet on the thank-you page (for example, your own landing funnel where you control the confirmation step). The pixel is simpler to drop in, but it inherits every fragility of browser-based tracking.

Many advertisers run postback as the primary source of truth and treat any pixel as a secondary signal. Because ShortlyLink dedupes by click id, if both a postback and a pixel fire for the same click, you still only count the conversion once.

Common gotchas worth knowing

• Signatures expire in 24 hours. Long attribution windows on the network side don't extend ShortlyLink's signature TTL. Late postbacks are rejected.
• A 409 is not an error you need to fix. It means the click already converted — the dedupe is doing its job.
• Set maxPayout deliberately. Leave it unset and the default cap of 1000 applies; set it too low and legitimate high-ticket payouts get clamped.
• The click id must survive the whole funnel. If the network drops or overwrites the cid you passed in, the postback comes back with nothing to match. Confirm your network is storing and returning the exact parameter you sent.

For a broader walkthrough of wiring this into a live campaign, see how to track affiliate conversions. You can review the full conversion, analytics, and redirect capabilities on the features page.

The bottom line

A postback URL is the most reliable way to track affiliate conversions because it takes the browser out of the equation entirely. ShortlyLink handles the hard parts for you — signing every click id on the way out, validating the signature on the way back with a timing-safe check and a 24-hour TTL, deduping repeats with a clean 409, clamping payouts, and normalizing statuses — so the revenue numbers on your dashboard reflect real conversions, not whatever survived the browser.

Ready to track conversions server-to-server? Start free at /register — no credit card, beta spots are limited.