Become an affiliateStart your program

Technology and tracking

Server-to-server tracking (postback)

Also called S2S tracking, postback, server-side tracking, postback URL.

Short answer

Server-to-server tracking (postback) is a tracking method in which the conversion is reported directly from the store's server to the network's server – bypassing the user's browser. The click ID follows the order, so the sale is recorded independently of ad blockers, cookie restrictions and closed browser tabs.

Definition of Server-to-server tracking (postback).

Server-to-server tracking rests on 3 steps: at the click, the network issues a unique click ID. The ID follows the customer to the store and is saved together with the order. When the order is completed, the store's backend calls a postback URL or an API at the network with click ID, order number and amount – and the conversion is recorded without any code running in the customer's browser.

The strength of the postback method is its independence from the browser. A tracking pixel can be blocked by an ad blocker, limited by Safari's ITP or fail to fire if the receipt page is closed too quickly. A server call is not affected by any of that – and it is the only method that can record events with no browser at all, such as a subscription renewal charged 30 days after the purchase while the customer is doing something else.

Its weakness is the requirement that the click ID survives all the way from click to order. If the ID is lost along the way – because it is not saved on landing or not carried through to the order – the postback has nothing to attribute to. In practice, the ID is therefore stored as first-party data on the store's own domain or directly in the order's fields.

You meet server-to-server tracking as webhooks from payment and shop platforms, as postbacks in mobile app tracking and as dedicated endpoints at affiliate networks. A shared requirement: the sender must be verifiable with a signature or a shared secret, so a conversion cannot be forged by anyone who knows the URL's format.

What a postback looks like

A classic postback is a single HTTP call: network.example/postback?click_id=abc123&order_id=1050&amount=499. The network looks up the click ID, finds program and affiliate and creates the conversion with the amount given. Modern variants send the same as signed webhooks with JSON – the principle is unchanged: server talks to server, and the same order ID may only count once, however many times the call is repeated.

Server-to-server vs. tracking pixel

AspectServer-to-server (postback)Tracking pixel
Where the code runson the store's serverin the customer's browser
Vulnerabilityunaffected by ad blockers, ITP and closed tabscan be blocked or fail to fire
Can trackalso events without a browser – such as renewalsonly events on a loaded page
Setuprequires backend access or a webhook integrationa script tag on the receipt page

The pixel is quickest to get running – server-to-server is what holds when the event happens without an open browser.

How it goes wrong

  • 01

    The click ID never arrives

    The postback can only attribute what it is given. If the click ID is not saved on landing, or not carried through to the order, the sale is recorded without an affiliate. Test the whole chain from click to postback – not just the call itself.

  • 02

    Unprotected postback URL

    A postback URL without a signature can be called by anyone who knows the format and used to invent conversions. Require a shared secret or signed calls, and reject order IDs that do not exist.

  • 03

    Pixel and postback count the same sale

    If a browser pixel and a server call run side by side without deduplication, the order is recorded twice. Deduplication on order ID must sit with the recipient – not be a promise from the sender.

At Affilyflow

Server-to-server tracking (postback) in practice

Affilyflow receives conversions server-to-server from Stripe and WooCommerce: Stripe reports purchases, subscriptions and renewals via webhooks, and the WooCommerce plugin reports the order from the store's server. The Shopify app, by contrast, reports sales with a Web Pixel in the browser. Attribution is decided on our server based on the click ID the conversion carries – not in the browser – and the attribution window was already locked at the click.

Security comes with it: we never ask for your Stripe API key, only for a webhook signing secret, and a store's webhook can only credit the store's own program. The same order can never count twice – orders are deduplicated on order and invoice ID per program – and every tracking event is logged, including those that did not become a sale.

Frequently asked questions

What is the difference between a postback and a tracking pixel?

A pixel runs in the customer's browser when the receipt page loads and can be blocked by ad blockers or the browser's tracking restrictions. A postback is sent from the store's server to the network's server and is not affected by the browser. The postback can also record events without a browser, such as subscription renewals.

Is a postback the same as a webhook?

Technically yes – both are server-to-server calls triggered by an event. Postback is the affiliate industry's term for the conversion call that goes from advertiser to network, while webhook is the general mechanism that, for example, Stripe and Shopify use to report orders.

Does server-to-server tracking require cookies?

The postback itself is cookie-free – it is a server call. But the click ID must survive from click to order, and in practice it is stored in first-party storage on the store's domain or directly in the order's data. Without a click ID on the order, there is nothing to attribute.

Why are postbacks used for subscriptions and apps?

Because the events happen without a browser. A renewal is charged automatically on the payment platform, and an in-app purchase happens in the app's backend – there is no receipt page to put a pixel on. Only a server call can record that kind of conversion.

Read on