The Complete Guide to Server-to-Server (S2S) Postback Tracking

S2S vs client-side pixel tracking

A client-side pixel is an <img> or JavaScript beacon fired from the advertiser's thank-you page in the visitor's browser. It depends on cookies or localStorage to remember which affiliate sent the click, and it fails silently whenever a browser blocks third-party requests.

An S2S postback is an HTTP request made from the advertiser's backend directly to the tracker's backend, carrying a click ID the tracker previously handed the advertiser. No browser is involved at conversion time, so no cookie, ITP restriction, or blocker can break it.

The click ID lifecycle

Every S2S flow revolves around a single opaque identifier — the click ID— that ties a click to its eventual conversion. Its lifecycle has four stages:

1. Mint. When an affiliate's tracking link is hit, LeadTrack generates a unique click ID and stores the click row (affiliate, offer, IP, user agent, geo, timestamp).
2. Forward. LeadTrack 302-redirects the visitor to the advertiser's landing page and appends the click ID to the destination URL as a query parameter (typically ?click_id=… or the advertiser's chosen macro key).
3. Store. The advertiser persists the click ID alongside the visitor — usually in a hidden form field or a session variable — so it survives to the conversion event.
4. Postback. On conversion, the advertiser's backend calls LeadTrack's postback URL with the click ID and any conversion metadata. LeadTrack looks up the original click row, records the conversion, and credits the affiliate.

Macro substitution reference

Macros are placeholder tokens in the destination URL that LeadTrack replaces with live click data at redirect time. The advertiser sees the resolved values; the template stays constant.

Reference implementation

LeadTrack accepts postbacks on a single public endpoint. The advertiser calls it from their conversion handler — a webhook, a database trigger, or the completion step of a checkout flow.

GET postback (simplest, works everywhere):

GET https://partners.leadmedia.in/api/public/postback
  ?click_id=abc123
  &payout=12.50
  &status=approved
  &external_txn_id=order_98765

Node.js example fired from a conversion handler:

async function fireConversion(clickId, order) {
  const url = new URL("https://partners.leadmedia.in/api/public/postback");
  url.searchParams.set("click_id", clickId);
  url.searchParams.set("payout", order.commission.toFixed(2));
  url.searchParams.set("status", "approved");
  url.searchParams.set("external_txn_id", order.id);
  const res = await fetch(url, { method: "GET" });
  if (!res.ok) console.warn("postback failed", res.status);
}

The external_txn_id field enables idempotency — replays of the same transaction are deduplicated instead of double-counted.

Verifying delivery

Every inbound postback lands in LeadTrack's Postback Diagnostics panel with the exact query string received, the resolved click, the response code returned, and the outcome (matched, deduplicated, or logged as a verified simulation for unknown click IDs). Advertisers can inspect the same log via the affiliate portal to confirm delivery.

Common pitfalls

• Stripping the click ID from the landing page URL before storing it.
• Firing the postback from the browser instead of the server — reintroduces the pixel's failure modes.
• URL-encoding an already-encoded click ID and creating a mismatch on lookup.
• Sending a bare status without a payout value, which breaks revenue reporting.
• Retrying failed postbacks without idempotency, causing duplicated conversions.