Postbacks and S2S Tracking: Getting Conversion Data You Can Rely On

Your dashboard says one number. The broker's dashboard says another. If you rely on browser-side tracking pixels to record conversions, the gap between those two numbers is not random noise — it is commission you have already earned and will never collect. Postback and server-to-server (S2S) tracking close that gap by moving conversion reporting off the trader's browser and onto a direct, server-side handshake between the broker and your tracking platform. This article explains how postbacks actually work, what parameters have to match for them to fire correctly, and how to audit a broker's S2S setup before you trust it with your commissions.

What a Postback Actually Is

A postback URL is an endpoint you give a broker or affiliate network. When a conversion event happens — a registration, a KYC pass, a first deposit, a funded trade — the broker's server sends an HTTP request straight to that URL, carrying the identifiers needed to credit the sale back to you. No script runs in the trader's browser. No cookie has to survive. The broker's backend simply tells your backend "this specific click converted, here is what happened."

This is the mechanism behind server-to-server tracking: server calls server, with the trader's device out of the loop entirely once the initial click is logged. It sits opposite tracking pixel methods, which fire a 1x1 image or JavaScript snippet from inside the browser at the moment of conversion — a method that depends on the page fully loading, the script executing, and no ad blocker, privacy browser, or in-app webview interfering.

If you have not yet read how the underlying click ID and cookie mechanics work end to end, start with how IB tracking actually works — this article assumes you understand clicks, sub-IDs, and the basic attribution chain, and goes deep on the S2S layer specifically.

Why Pixel Tracking Breaks and S2S Doesn't

Pixel-based conversion tracking fires client-side, from the trader's browser, at the moment the "thank you" or "account confirmed" page loads. Every one of these can silence it:

• Ad blockers and privacy extensions strip third-party tracking scripts before they load.
• Mobile app webviews and some broker mobile apps never load the full confirmation page, or load a native screen instead.
• Slow page loads or navigation away before the pixel fires (a trader closing the tab a half-second early).
• Browser privacy modes (Safari's Intelligent Tracking Prevention, Firefox Enhanced Tracking Protection) that block third-party trackers by default.
• Cross-device conversions — a trader clicks your link on mobile, then completes KYC on desktop days later, breaking any cookie tied to the original device.

None of these touch a postback, because the postback is fired by the broker's own backend after the broker's own database confirms the event happened. The trade-off is that S2S tracking requires the broker to build and maintain that server-side integration correctly — which is where the risk moves from "silent browser failure" to "silent broker misconfiguration." Both failure modes cost you the same thing: unreported conversions. The difference is where you have to look to catch them.

How the Postback Flow Actually Works, Step by Step

1. A trader clicks your affiliate link. Your tracking platform (or the broker's own affiliate portal) generates a unique click ID — a random string that identifies this specific click, this specific sub-ID, this specific campaign.
2. The click ID travels with the trader into the broker's registration flow, usually appended as a URL parameter or stored in the broker's own session against the new account.
3. The trader completes a tracked event — registers, passes KYC, deposits, or places a qualifying trade, depending on what the deal structure pays on.
4. The broker's server fires an HTTP request to your postback URL, passing back the original click ID plus event data: transaction ID, event type, currency, and (for CPA or hybrid deals) the payout amount.
5. Your tracking platform matches the returned click ID to the original click and logs the conversion against the correct sub-ID and campaign.

The entire exchange happens between two servers, asynchronously, with no dependency on the trader's device being online, unblocked, or even still using the same phone or laptop they clicked on. This is also why the practice matters directly for multi-broker attribution: each broker fires its own postback independently, so a clean per-broker integration is what makes cross-partner reporting trustworthy in the first place.

The Parameters That Have to Match — or Nothing Fires

A postback is a URL template with placeholder variables ("macros") that the broker fills in at send time. The names differ by platform — one network uses {click_id}, another {aff_sub}, another {cid} or {transaction_id} — but the concept is identical everywhere: your tracker exposes macros, the broker substitutes real values into them, and if the mapping is wrong on either side, the postback either doesn't fire or fires with garbage data your system can't match to a click.

Vetting a Broker's Postback Setup Before You Trust the Numbers

Before you commit real traffic volume to a broker, run a live test rather than taking their documentation at face value.

1. Register a test account through your own tracking link with a sub-ID you control, and note the click ID your tracker generated.
2. Complete the full funnel yourself — registration, KYC, a small deposit — using realistic values.
3. Check your tracker's postback log, not just the summary dashboard, for the raw incoming request and confirm the click ID matches.
4. Time the delay. Some brokers batch postbacks hourly or daily rather than firing in real time; know which before you plan reporting around it.
5. Deliberately break one step — abandon KYC halfway, or use an ad blocker on the confirmation page — to confirm the postback still fires (this is the whole point of S2S over pixels).
6. Ask for their event dictionary — the full list of event types and macros they support — in writing, not verbally from an account manager.

This same discipline is the core of auditing a broker's reporting dashboard before you trust their numbers at scale — postback verification is the technical half of that audit; the reconciliation-against-your-own-records half is the other.

Postback vs. Pixel: When Each Still Shows Up

Most modern broker programs default to S2S because it is more robust, but pixel tracking has not fully disappeared. Some brokers still fire a pixel for real-time on-page confirmation (useful for instant "thank you" messaging) alongside a postback for the authoritative record. Others, especially smaller or newer broker affiliate programs, still run pixel-only tracking because it is cheaper to implement on their side.

The distinction matters most around cookie windows and attribution — a pixel-only setup is far more exposed to the same browser and device issues that erode cookie-based attribution windows, compounding the loss.

Common Mistakes IBs Make With Postback Setups

• Never testing the postback before scaling traffic. The first time many IBs check whether a postback fires correctly is when a monthly reconciliation already shows a shortfall.
• Ignoring event-type granularity. If a broker's postback only ever fires "conversion" with no distinction between registration and deposit, you lose the ability to optimize which sub-ID or channel produces payers, not just leads.
• Not confirming currency normalization. A postback reporting raw payout in the broker's base currency, mixed into a dashboard expecting your reporting currency, silently distorts revenue totals.
• Trusting a broker's summary dashboard over the raw postback log. Dashboards aggregate; postback logs show you the actual request that arrived, which is what you need to debug a discrepancy.
• Assuming one broker's macro names apply everywhere. Copy-pasting a postback URL template from one broker's integration into another's platform, without remapping the macros, is a common cause of a postback that silently never fires.

Where the Partner Bridge Fits

Every term here — click ID, postback, S2S, event type — is a piece of shared vocabulary across brokers, exchanges, and prop firms, and the exact implementation details still vary partner to partner. Before signing with a new partner, it is worth building fluency in the full attribution vocabulary so you know exactly what to ask their integration team. Revenika's partner glossary covers the tracking, payout, and compliance terms you'll need across every market you evaluate.

Frequently Asked Questions

Do I need my own tracking platform to use postbacks, or can I rely on the broker's dashboard alone?

You can technically operate on a broker's dashboard alone, but doing so means you have no independent record to reconcile against. A basic third-party or self-hosted tracker that receives the broker's postback gives you a second, broker-independent ledger — the single most useful tool for catching underreporting early.

What happens if a postback fires twice for the same conversion?

A well-built postback includes a unique transaction or order ID specifically so your tracker can deduplicate repeat sends. If a broker's postback lacks this field, ask for it explicitly — without it, retries or broker-side bugs can inflate your reported conversions.

Is S2S tracking harder to set up than a tracking pixel?

The initial setup takes more coordination, because both sides must agree on macro names, event types, and (ideally) a security token. Once configured correctly, though, S2S requires far less ongoing maintenance than a pixel, which can silently break with any browser or ad-blocker update.

Can a broker fake or manipulate postback data?

In principle, yes — a postback is only as trustworthy as the broker sending it. This is exactly why independent verification (test conversions, comparing postback logs to your own funnel data, and periodic reconciliation) matters, alongside the due-diligence checks in choosing which partners to trust in the first place.

Does postback tracking work across multiple devices?

Yes — that's one of its core advantages. Because the click ID is stored server-side (typically against the broker's own account record) rather than in a browser cookie, a trader who clicks on mobile and converts on desktop days later can still be attributed correctly, as long as the broker's backend correctly persists the click ID across the session.

Conclusion

Postback and S2S tracking exist because browser-side pixels were never a reliable place to store commission-critical data. A postback moves that responsibility to the broker's own server, which is more durable — but only as good as the integration behind it. Test every new broker's postback before scaling traffic, verify the macros and security token match on both sides, and keep an independent log so a broken or manipulated postback shows up as a discrepancy you can catch, not a quiet loss you only discover months later.