Key takeaways
- A postback reports a conversion into your tracker; a webhook pushes events out of your tracker to other systems.
- Both are server-to-server HTTP calls, which is what makes them reliable and cookieless.
- Postbacks carry the click ID inward to attribute a conversion; webhooks notify your stack when something happens.
- Make both robust with retries, idempotency keys, and signed payloads.
- Afflio uses cookieless S2S postbacks for attribution and outbound webhooks to keep your systems in sync.
Postbacks and webhooks get conflated because both are server-to-server HTTP calls — but they point in opposite directions and do different jobs. A postback brings a conversion into your tracker so attribution can happen. A webhook pushes events out of your tracker so the rest of your stack can react. Knowing which is which, and how to make each reliable, is core to running tracking that doesn't silently lose data.
What is a postback?
A postback is a server-to-server request that reports a conversion to your affiliate tracker, carrying the click ID so the conversion can be attributed. When an order completes, the advertiser's server calls the tracker's postback URL with the click ID, conversion value, and order reference, and the tracker matches it to the affiliate who owned that click.
Because the postback travels server to server and is keyed on a click ID rather than a cookie, it's the backbone of cookieless attribution — it works regardless of what the user's browser does with cookies.
What is a webhook?
A webhook is an outbound server-to-server request your tracker sends when an event happens, so other systems can react in real time. Where a postback feeds a conversion in, a webhook notifies out: a conversion was approved, a commission was created, a payout was sent. Your CRM, data warehouse, or Slack can subscribe and stay in sync without polling.
- Conversion approved — trigger downstream fulfillment or analytics.
- Commission created — update your finance system.
- Payout sent — notify the partner or log it for reconciliation.
- Fraud flag raised — alert your operations channel.
How are postbacks and webhooks different?
They differ in direction and purpose: a postback comes in to report a conversion for attribution; a webhook goes out to notify other systems of an event. Both are server-to-server, so they share the same reliability requirements, but you wire them for opposite flows.
Direction is the whole distinction
If you only remember one thing: postbacks are inbound attribution (something tells the tracker a conversion happened), webhooks are outbound notification (the tracker tells your systems something happened). Same transport, opposite direction, different job.
How do you make postbacks and webhooks reliable?
You make them reliable with three habits: retries for transient failures, idempotency so retries don't double-count, and signing so you can trust the sender. Server-to-server calls fail in normal operation — timeouts, brief outages — so the design has to assume failure and recover from it.
- Retries with backoff: if a call fails or times out, retry on a schedule rather than dropping the event.
- Idempotency keys: include a unique reference (the order ID for postbacks, an event ID for webhooks) so a retried delivery is recognized and not processed twice.
- Signed payloads: sign requests with a shared secret so the receiver can verify the call genuinely came from the expected sender and wasn't spoofed.
- Acknowledge explicitly: the receiver should return a clear success status so the sender knows when to stop retrying.
Retries without idempotency is how you turn one conversion into five. The retry is what saves you from data loss; the idempotency key is what saves you from the retry.
Afflio uses cookieless S2S postbacks to bring conversions in for attribution and outbound webhooks to push events to your systems, with order references on conversions for idempotency. That means attribution survives browser privacy changes on the way in, and your finance, CRM, and analytics stay in sync on the way out — without duplicate processing or spoofed calls.
What is the difference between a postback and a webhook?
Direction and purpose. A postback is an inbound server-to-server call that reports a conversion to your tracker so it can be attributed via the click ID. A webhook is an outbound call your tracker sends to notify other systems of an event, such as a commission being created or a payout being sent.
Are postbacks and webhooks affected by cookie blocking?
No. Both are server-to-server HTTP calls between backends, so they don't rely on cookies in the user's browser. That's why postback-based attribution is described as cookieless and survives browser privacy changes that break pixel-and-cookie tracking.
How do I stop postbacks and webhooks from double-counting?
Use idempotency keys. Include a unique reference — the order ID for postbacks or an event ID for webhooks — so that retried deliveries are recognized and processed only once. This is essential because you should retry failed calls, and retries without idempotency cause duplicates.