S2S Postbacks Explained

A server-to-server (S2S) postback records a conversion by having one backend system send the data directly to another. The advertiser's server reports the sale, signup or install to the tracker's endpoint, and no browser or cookie takes part in that report. Anyone who configures tracking meets this mechanism on every serious network, and the same pattern repeats across the tools in affiliate trackers compared. The concept is simpler than the acronyms suggest, but the details decide whether conversions land or vanish.

Why browser-based tracking broke first

The older method, pixel tracking, places a small piece of code on a confirmation page. The code fires from the shopper's browser when the page loads and tells the platform a sale happened. It works until the browser interferes.

Cookies get blocked or deleted, ad blockers stop the pixel from firing, and a shopper who closes the tab before the confirmation page loads leaves no record at all. WebKit documents that Safari's Intelligent Tracking Prevention blocks all third-party cookies by default and deletes script-written storage after seven days without user interaction. Every one of these failures is a real conversion that a partner drove and does not get credited for. How much is lost depends on the browser mix, the traffic and the setup, so no single figure applies.

What server-to-server tracking is

S2S tracking moves the conversion record off the shopper's browser and onto the backend. Instead of asking a browser to report the sale, the advertiser's own server sends the data directly to the tracker's server, machine to machine.

Nothing the browser does at the moment of conversion can break the record, because the browser is never asked to do anything then. The connection links two events: a visitor's click on a trackable link, and a later action the advertiser records, such as a signup, an approved lead, a sale, a subscription or a first payment. The link between them is a unique identifier, usually a click ID.

Postback tracking is deterministic only when the same valid identifier appears on both sides of the journey. If the click ID is lost before the conversion, the server request cannot reconstruct the missing referral on its own. That single dependency explains most of the failures covered below.

The click-ID round trip, step by step

1. A visitor opens a tracking link. The tracker records the traffic source, campaign and any sub-parameters, then creates a unique click ID.
2. The tracker passes the click ID to the destination, usually as a URL parameter, and redirects the visitor to the offer.
3. The advertiser captures the click ID and stores it in a server-side session, lead record, customer record or order metadata.
4. The visitor completes the agreed action. This can be an early event such as registration or a later one such as approval or first payment.
5. The advertiser's backend fills a postback template with real values and makes an HTTP request to the tracker's endpoint.
6. The tracker validates the request, finds the click record, checks whether the transaction was already processed and applies its attribution rules.
7. The conversion appears in reporting, often as pending, approved or another configured status.

The click ID is the thread that ties the conversion back to the click that caused it. The postback URL is the agreed address the result goes to. The shopper's browser only carries the identifier in at the start; it does not fire anything at conversion time.

What a postback URL looks like

A postback URL is an endpoint that receives conversion information. It contains fixed values and placeholders called macros or tokens, and at runtime the sending system replaces each macro with the value from the actual event. Postbacks are ordinary HTTP requests; MDN notes that the query component of a GET request often carries identifying information as key=value pairs, which is exactly how the fields below travel.

A generic template, with placeholder names that belong to no particular vendor:

https://tracker.example.com/postback?click_id={click_id}&transaction_id={transaction_id}&event={event}&amount={amount}&currency={currency}

Reading it from left to right:

• https://tracker.example.com/postback is the receiving endpoint on the tracker. Use HTTPS.
• click_id={click_id} returns the identifier created at the click. This is the field the tracker uses to find the original visit.
• transaction_id={transaction_id} is a unique ID for this business event, such as an order number. It is the key for deduplication.
• event={event} names the conversion type, for example a registration, a purchase or a renewal.
• amount={amount} and currency={currency} carry the value and its currency code, if the contract calls for them.

When an order completes, the sending system substitutes the stored click ID, the order ID, the event name, the amount and the currency, then makes the request. The example is illustrative only: parameter names, macro syntax and supported fields vary by platform, and copying a template from one system into another without mapping its macros is a common cause of missing or unattributed conversions. The documentation of the network or tracker in use is the authority on its own syntax.

Macros, parameters and runtime values

A macro is a placeholder understood by the sending system. A parameter is the field expected by the receiving endpoint. A correct postback maps one to the other. If a receiving platform expects click_id while the sending platform exposes the stored value under another name, the configuration maps them as click_id=<sender's macro>. The names do not need to match, but the values and meanings must.

Macro syntax differs across systems. Curly braces, square brackets and percent signs are all seen, and documentation lists the fields under headings such as sub-ID, tracking parameter or S2S tracking.

Before launch, a mapping sheet should record the parameter the receiver expects, the macro the sender supplies, whether the field is required, the allowed type and length, and how missing values are handled. Amounts need an agreed decimal format, currency a consistent code, and timestamps a documented time zone.

Values also need URL encoding. RFC 3986 defines percent-encoding as the percent sign followed by two hexadecimal digits representing an octet, and it is what keeps a space, an ampersand or other special character in a free-text field from breaking the query string.

The identifiers in a postback

A transaction ID should stay stable when the same event is retried. Generating a new one for every retry makes a single conversion look like several. The click ID is the only field most systems insist on; without a recognised one, many platforms reject the incoming conversion.

Two directions a postback can travel

The word describes two different connections, and mixing them up means installing the wrong URL in the wrong system.

In a multi-system campaign the buyer's tracker creates its own click ID and passes it to the network as a sub-parameter. When the advertiser reports the conversion, the network returns that upstream ID in the partner postback. Each hop needs a documented parameter map, and a break at any hop leaves the conversion unattributed downstream.

Postback versus pixel

Neither method is universally correct. A small store may begin with a pixel, while a lead business with delayed qualification benefits from server-side status reporting. Many programs run both, with S2S as the primary method and the pixel as a fallback. When both run, they must share a transaction ID or another deduplication rule so the same action does not create two commissions.

Where postbacks are used

E-commerce backends report approved orders with a click ID, a unique order ID, an amount and a currency. Later cancellations and refunds need explicit handling, because a refund is a separate lifecycle event rather than a correction of the original one.

Lead generation stores the click ID in the CRM at form submission and may fire the postback only when the lead is accepted. A pending event can be reported first and updated after qualification.

Subscription and software businesses report trial registration, paid activation, upgrade, renewal and cancellation. A customer identifier maintains the relationship, while a unique transaction ID distinguishes each billing event. App businesses report installs and in-app events the same way. In all cases the affiliate marketing overview puts the advertiser-partner relationship behind these events in context.

Setting up postback tracking

Setup follows the same shape on any platform. The steps describe the concept rather than one vendor's interface, and what a tracker does covers the receiving side in more detail.

1. Define the conversion contract. List every event, its required fields, its qualification rule and whether the initial event is pending or approved. A contract written before any code prevents most disputes later.
2. Map every identifier. Trace the click ID from the tracking link through redirects, landing pages, forms, CRM records and checkout to the final request. A lead business may save the click ID at form submission, while a store attaches it to the cart or order.
3. Configure the receiving endpoint. Build the postback URL from the receiver's parameter names and the sender's macros, and validate allowed values. This is also the moment for checking postback settings with a network, since CPA networks name and format their fields differently.
4. Add duplicate and retry handling. Choose the key that makes a repeated event harmless and define how the sender reacts to success, timeout and error responses.
5. Test the whole lifecycle. One successful request is not a test (see the next sections).
6. Reconcile before launch. Compare row-level conversions between the advertiser, the tracker and any connected partner system. Totals alone cannot show which transaction is missing or duplicated.
7. Monitor production. Watch success rate, retries, unmatched identifiers and duplicates, and assign an owner for integration alerts.

Deduplication, retries and status updates

Network timeouts create an unavoidable question: did the receiver process the event before the connection failed? A sender may retry because it never got a response, even though the first request was accepted.

Idempotent processing means repeating the same logical event does not create an additional conversion or commission. The HTTP standard has the same idea for methods: RFC 9110 defines an idempotent method as one where multiple identical requests have the same intended effect on the server as a single one, and says some requests can be retried automatically after a connection failure. A postback is only safe to retry if the receiver treats it that way, which is why a stable transaction ID paired with the event type is the usual key. One order plus a purchase event creates the purchase once. The same order plus a refund can be a separate event if the contract supports it.

Deduplication rules must reflect the business model. An order can contain several items and a subscription can renew many times, so using the customer ID alone as the unique key would suppress legitimate recurring events.

Retry policies depend on the receiving platform. Bounded retries, logged outcomes and alerts keep an outage from turning into a flood of duplicate requests.

Many journeys contain several events: registration, verification, approval, first payment, renewal, refund, cancellation. Each needs a clear name, a unique-key rule and a commission consequence. The design should state whether a status update modifies an existing conversion or creates a separate one, because mixing the two without a rule produces duplicates and unexplained commission changes.

Security and fraud controls

A postback endpoint is an external interface and should be treated as one. Authenticate the sender with a shared secret, token, signature or another supported mechanism, since an obscure URL is not protection. Restrict trusted sources where the sender publishes stable addresses, but do not rely on that alone. Validate every field: identifier format, goal validity, amount, currency and length. Use HTTPS and keep personal data out of URLs, because query strings can appear in application, proxy and monitoring logs. Keep an audit trail of when each request arrived, how it was authenticated and why it was accepted or rejected.

Moving tracking server-side removes a category of browser-based tampering, but it is not a cure-all. Fake conversions can be fired straight at an unprotected postback URL, and a valid-looking identifier does not prove that the action was legitimate. Signed requests, replay detection and post-sale validation from payment or CRM systems raise the bar.

What S2S improves, and what it does not

S2S reduces dependence on the conversion browser. The backend can report a conversion even when a pixel would be blocked, and it can wait until a lead is verified or a payment succeeds before firing. Values such as amount and currency come from trusted order records rather than client-side code.

Three things do not follow automatically. Cross-device attribution still needs a permitted shared identifier or an authenticated account, since a server request cannot connect unrelated device sessions without a matching key. Fraud prevention still needs validation rules and business data. Privacy compliance still requires a defined lawful basis, retention and access controls, because the systems process identifiers and may exchange customer data. No tracking method captures every conversion perfectly, and the goal is resilience rather than a perfect count.

Testing a postback before it goes live

Postback URLs are fired by servers, so nobody can watch the data move, and the fix is an event log on the receiving end. A test conversion should show a clear status when the postback arrives and matches a click ID, and a named error when it does not. The two failures met most often are a missing click ID, which usually means the links are not tagged, and a no-match result, which usually means the capture step is missing.

A manual fire is also possible. A postback is an HTTP request, so pasting the URL with literal values into a browser address bar sends a GET request, which is enough to check that the endpoint responds and authentication passes.

Checklist for a full test:

• Every test click receives a unique click ID, and the ID survives all redirects and funnel steps.
• The advertiser stores the value in the intended backend record.
• Every macro-to-parameter mapping is correct and values are URL-encoded.
• One successful conversion is attributed to the right source and campaign.
• The same transaction sent again is not counted twice.
• Every configured goal is tested separately, including amount and currency.
• A simulated timeout or server error triggers a controlled retry.
• Pending, approved, rejected and reversed statuses behave as agreed.
• Advertiser, tracker and finance reports use the same time zone.
• Secrets and personal data are removed from shared logs and screenshots.

Common S2S tracking problems

Reliability can be measured: delivery success rate, match rate, duplicate rate and variance against the advertiser's records. A falling match rate usually points at lost click IDs, a rising duplicate rate at retries, and a change in approval rate may reflect traffic quality or a data problem rather than fraud.

FAQ

What is a postback URL in simple terms?

It is an endpoint that one server calls to tell another server that a conversion happened. The URL carries the click ID from the original click plus details such as an amount and a transaction ID. The receiving system matches the click ID to the stored click and credits the conversion, with no browser involved.

How is S2S tracking different from pixel tracking?

A pixel fires from the shopper's browser when a confirmation page loads, so it depends on cookies, scripts and the page loading fully. A postback fires from the advertiser's server when the action is confirmed. Many programs run S2S as the primary method with the pixel as a fallback.

Is S2S tracking immune to ad blockers?

The backend conversion request is generally not exposed to browser ad blockers, which is the main reliability gain. The wider journey can still fail if the tracking link, a redirect or the capture of the click ID is blocked or misconfigured. The method is more resilient, not immune.

Can a postback be retried safely?

Yes, if the same transaction ID is reused so the receiver can process the event idempotently. Temporary network and server errors justify bounded retries, while invalid or unauthorised requests should be corrected rather than retried.