Server-to-Server Postback Setup: What to Know Before You Start

Server-to-server (S2S) postbacks are the backbone of reliable conversion tracking in affiliate, ad-tech, and SaaS billing environments. Unlike client-side pixels, which depend on a browser, cookie state, ad blockers, and JavaScript execution, an S2S postback is an HTTP request fired from one server to another. That shift moves the entire trust boundary: you no longer ask "did the browser tell us?" but "did the server confirm it?" This article covers what you need to settle before writing a single line of integration code.

What an S2S Postback Actually Is

A postback is an outbound HTTP call made by an advertiser, network, or billing platform to a tracking endpoint, carrying parameters that describe an event — a click ID, a conversion value, a status, a timestamp. In the classic affiliate flow, the network issues a unique click identifier (often called click_id, subid, or aff_sub depending on the vendor), the advertiser stores it at the moment of the click, and later fires it back to the network alongside the conversion data. The network matches the identifier to its own record and attributes the conversion.

Technically, this is almost always a GET request with query-string parameters, or a POST with a JSON or form-encoded payload. GET is easier to debug and log but leaks data into access logs and referrer chains; POST is cleaner for sensitive payloads and larger bodies but complicates manual testing. Either way, the mechanics are the same as any REST call — you are sending structured data from a machine you control to a machine someone else controls, and you must assume that call will sometimes fail.

If you want the mechanics of attribution in more depth before designing your endpoint, it helps to study how postback conversions work from the receiving side as well as the sending side — understanding both perspectives prevents most integration mistakes.

Prerequisites: Define the Contract Before You Code

The most common failure mode in S2S integrations is not a bug — it is an undocumented assumption. Before implementation, agree on the following in writing, ideally in a shared spec document:

• Endpoint and method: exact URL, HTTP method, content type, and whether the receiver expects GET query params or a POST body.
• Parameter set and names: every macro, its exact spelling (case-sensitive), and its type. click_id and ClickID are not the same key.
• Event taxonomy: which status codes represent a registration, a trial, a paid conversion, a refund, or a chargeback, and how they map to the receiver's status values.
• Value format: currency code, decimal separator, minor-vs-major units (cents vs. dollars), and rounding rules.
• Response contract: what the receiving endpoint returns on success (typically HTTP 200), on duplicate events, and on invalid parameters — and what your sender does with each.
• Slug conventions: the format of the tracking identifier, its maximum length, and whether it is opaque or structured.

Ambiguity in any of these turns into silent data loss later. A parameter spelling mismatch, for example, does not throw an error — the receiver simply receives a null and drops the event, and you learn about it days later when the numbers do not reconcile.

Transport, Security, and Reliability

Postbacks traverse the public internet, which means they are subject to the same reliability and security concerns as any webhook. Treat them accordingly.

Transport. Enforce HTTPS on both ends. Some legacy networks still accept HTTP, but that means click IDs and conversion values travel in plaintext and are trivially forged or replayed by anyone who observes them.

Authentication. Most networks do not implement signing schemes, so the common practical controls are: a long random secret embedded in the endpoint path or as a query parameter, IP allowlisting on the receiving side, and, where the receiver supports it, HMAC signatures over the payload. Check what your counterpart offers before assuming the endpoint is protected.

Idempotency. Every postback should carry a deduplication key — usually a transaction ID or a composite of click ID plus event type plus a timestamp bucket. The receiver must reject repeats; the sender must not assume that a network timeout means the event was lost. Without idempotency keys, retries create double-counted conversions, and those are painful to unwind in billing.

Retries and backoff. Servers go down, certificates expire, and load balancers return 502s. Configure retries with exponential backoff and a bounded retry count, and distinguish between retryable failures (5xx, timeouts, connection resets) and terminal ones (4xx). A 400 from a malformed parameter will never succeed on retry — retrying it just wastes capacity and pollutes logs.

Logging and observability. Persist the raw request line, headers, payload, response status, and response body for every postback attempt, on both sides if possible. When attribution disputes arise — and they do — these logs are the only evidence that settles them.

A Concrete Implementation Sequence

Assuming a sender-side implementation where your system fires postbacks to an affiliate network, a reasonable order of work looks like this:

1. Capture and persist the identifier. At click or session start, store the incoming tracking parameter against the user or session record. Do not rely on cookies or client storage that can be cleared; server-side persistence is the point of S2S.
2. Map events to statuses. Build an explicit lookup table from your internal event types to the receiver's status codes. Keep it in configuration, not hard-coded in application logic.
3. Build the payload. Assemble parameters from your stored record and the event context, URL-encode correctly, and validate against the spec's types before sending.
4. Send asynchronously. Queue the postback in a durable job queue with retry policy attached. Never fire postbacks synchronously inside the user-facing transaction path — a slow receiver should not slow down your checkout.
5. Record the attempt and parse the response. Store the outcome and update the event's delivery state. Surface non-2xx responses to monitoring.
6. Reconcile. Run a daily job comparing your sent events against the receiver's reported conversions; configure an alert threshold for mismatch rates. Anything above roughly 1–2 percent warrants investigation.

If you would rather start from a working reference than from a blank spec, you can xpnsr.com about established postback conventions and parameter layouts before building your own pipeline.

Testing and Go-Live Checks

Postback bugs rarely announce themselves. They hide in edge cases: the click ID that contains a plus sign and gets decoded as a space, the currency value that uses a comma decimal separator, the retry that fires after the user has refunded, the event that arrives out of order. Before go-live, work through a checklist:

• Fire a test postback with every status code in the taxonomy and confirm the receiver records each correctly.
• Send a deliberately duplicate event and confirm it is rejected or de-duplicated, not double-counted.
• Simulate a timeout and a 500 response and verify retry behavior and eventual delivery state.
• Test with real-world identifier formats, including special characters, maximum-length slugs, and empty values.
• Verify timezone handling: timestamps should be UTC on the wire, without exception.
• Confirm that refunds and chargebacks generate their own events rather than mutating the original conversion.

It is also worth remembering that these conventions are not new. The separation of a client-side signal from a server-side record of truth echoes older patterns in computing, where the authoritative account of an event has always lived in a system of record rather than at the edge; Encyclopaedia Britannica has documented the broad history of record-keeping and data processing for readers who want the longer view.

Get the contract right, make the pipeline idempotent and observable, and test the failure paths — not just the happy one. Do those things and your S2S postbacks will reconcile cleanly month after month. Skip them and you will spend your first quarter of live traffic rebuilding trust in your own conversion numbers.