Affiliate pixels and postbacks: notifying your partners when a conversion lands

There are two directions a conversion pixel can point, and confusing them is one of the most common reasons an affiliate integration goes quiet. An advertiser conversion pixel points inward: it tells your platform that a sale or lead happened. An affiliate pixel points outward: it tells your partner's system that one of their conversions was recorded, so their own dashboards, their own optimization, and their own sub-network reporting stay in sync with yours. This guide is about the outbound direction — how affiliate pixels work, why the reliable kind and the fragile kind exist, and the security discipline that keeps your program's economics from leaking to the people you pay.

Why partners want a pixel at all

An affiliate rarely runs traffic to just one program. They buy media, they run their own funnels, they may have sub-affiliates of their own, and they need a single source of truth for what converted. If they had to log into your portal and reconcile by hand, your program would be a black box in the middle of their operation. An affiliate pixel closes that loop automatically: the moment you record a conversion attributed to a partner, their system hears about it in near real time, with the details they need to attribute it on their side. Good partners ask for this early, and being able to offer it cleanly is a mark of a serious program.

The two kinds, and why it matters which

There are two mechanisms, and the difference between them is the single most important thing to understand.

A server-to-server postback URL is a link the platform calls from its own servers every time a conversion is recorded for that partner, no matter how the conversion arrived — browser pixel, server postback, or manual entry. Because it fires server-side, it does not depend on the visitor's browser, cookies, ad blockers, or whether anyone's page finished loading. This is the reliable choice, and it is the one to recommend by default. It is the same server-to-server philosophy that makes inbound conversion pixels and postbacks trustworthy, pointed the other way.

An HTML pixel is a snippet that renders in the visitor's browser at the moment of conversion. It only fires when the conversion itself was recorded through the browser — specifically when the advertiser's conversion pixel is installed in a browser-rendered variant that can carry the affiliate's snippet along. A conversion that arrives by server postback never renders an HTML pixel, because there was no browser in the loop to render it. This is not a quirk of one platform; it is a structural limit of browser-based firing everywhere. The practical takeaway: HTML pixels are for the specific cases a partner genuinely needs them, and server-side postbacks are for everything else.

Scope: global, per-offer, or per-event

A partner rarely wants the same notification for everything. A pixel can be registered at one of three tiers of specificity: for a single event on a single offer, for a whole offer, or globally across every offer the partner runs. When a conversion records, the most specific matching pixel wins — an offer-level pixel takes precedence over a global one for that offer — so a partner can set a broad default and then override it precisely where a particular offer or event needs different handling. Keeping a sensible cap on the number of pixels per scope prevents a partner from accidentally firing a dozen near-duplicate notifications for one conversion.

Tokens: putting the right data in the notification

A postback is only useful if it carries the conversion's details, and that is what tokens do. A partner drops placeholders into their URL or snippet — a conversion identifier, the click identifier, the offer, the payout, the sub-IDs they tagged the traffic with — and the platform substitutes the real values at the moment it fires. This is how a partner's system knows which click converted and how much they earned, so it can attribute the result back to the campaign or source that drove it. Sub-IDs are especially important here, since they are how a partner tells their own sources apart; the sub-ID guide explains why they are worth tagging on every link.

Because pixels are so often copied between platforms, a good implementation quietly accepts the token names other tools use, so a partner's pasted template keeps working without a rewrite. Unknown tokens should produce a warning rather than silently corrupting the URL.

The rule that protects your margin

Here is the discipline that separates a safe integration from a leaky one: the only earnings figure an affiliate pixel may carry is the affiliate's own payout. What the advertiser pays you, your margin, and your revenue are yours alone, and they must never be substitutable into an outbound pixel. A well-built platform rejects revenue-style tokens outright, with a clear message, rather than firing them. This is not paranoia — a partner who can see your margin can negotiate against it, and a partner who accidentally logs your revenue in their system has your commercials in a place you do not control. The same boundary runs through the whole affiliate portal: partners see their payout and their traffic, never your economics.

Security is not optional on an outbound call

An affiliate pixel makes your servers call a URL that a third party supplied, which is a capability worth treating carefully. Sensible platforms enforce a floor: the destination must be a public host reachable over a secure connection on the standard port, private and internal addresses are blocked, and redirects are not followed. These rules prevent an outbound pixel from being turned into a probe of your own infrastructure, and they are the reason a legitimate partner URL fires while a malformed or suspicious one is refused and logged as blocked.

Approval: who gets to add a pixel

Because a pixel causes your servers to make outbound calls with conversion data, partner-submitted pixels should pass through a review step before they go live. Most programs keep a light touch here — a per-partner or program-wide auto-approve setting for trusted relationships, with review reserved for new or unusual submissions. Pixels an administrator adds on a partner's behalf can be trusted immediately. The point is not friction; it is that adding an outbound data channel is a decision, and someone should own it.

"Did it fire?" — reading the log

The most frequent support question about affiliate pixels is simply whether one fired, and a program should be able to answer it definitively rather than guessing. Every fire should be recorded with its outcome: fired for a clean success, failed for a rejected response, timeout when the partner's server did not answer, blocked when the URL failed the security checks, and served for a browser-side HTML pixel whose delivery cannot be observed from the server. A tenant-wide fire log, a per-conversion view, and a partner-facing recent-fires list together mean nobody has to speculate. Test conversions, sensibly, never fire real pixels — you do not want a partner's system reacting to your QA.

When a pixel that should have fired did not, the checklist is short and mechanical: is it approved and active, does its scope match the conversion, was the conversion real rather than a test, is the event actually published to partners, and — for HTML pixels — did the conversion arrive through the browser at all? The broader diagnostic flow, including how to read the fire log alongside the inbound pixel log, lives in the pixel log troubleshooting guide.

Why this is worth getting right

Affiliate pixels are the handshake between your program and your partners' systems, and the quality of that handshake shapes the relationship. Reliable server-to-server notifications keep partners' numbers in sync with yours, which cuts reconciliation disputes to near zero. A hard boundary around your economics keeps your margin private no matter how many partners you onboard. And a complete fire log turns "your pixel is broken" from a standoff into a diagnosable event. All of it rests on the same first-party tracking foundation that records the conversion in the first place — the tracking feature overview shows how that record is captured, and a demo will wire a partner postback end to end on your own data with you.