Why postbacks exist
Most ad platforms now offer at least one of: a pixel, a CAPI-style API, or a postback URL. The postback URL is the simplest possible interface: when a tracked event happens, you make an HTTP request to a URL the platform gave you, with the click ID and conversion details in the query string.
This minimalism is why postbacks have survived for two decades while richer tracking patterns came and went. They work over any HTTP stack, require no SDK, and are easy to debug, you can curl them by hand.
How postbacks work
Step by step:
- Ad platform appends a click ID to outbound URLs (e.g.
?gclid=..or?fbclid=..) - Your site captures and persists the click ID
- User converts (purchase, signup, install)
- Your server fires an HTTP request to the postback URL, including the click ID, event type, value, and any other required parameters
- The ad platform records the conversion against the original click and credits attribution accordingly
The full conversion loop happens server-side after the initial click.
Where postbacks dominate
Three contexts where postbacks remain the primary integration:
- Mobile attribution. Apple’s SKAdNetwork uses postbacks. So do AppsFlyer, Adjust, Singular, and other MMPs. The mobile world ran on postbacks long before web tracking caught up.
- Affiliate networks. CJ, Rakuten, Impact, Awin, all use postback URLs to report conversions back to publishers.
- In-platform server-to-server. Even when a platform also offers a richer SDK, the postback URL is the lowest-friction fallback.
Postback vs CAPI
Both are server-to-server. The differences:
- Postback is typically a simple HTTP GET with query parameters
- CAPI is typically a richer HTTPS POST with a JSON body and authentication
- Postback is often unidirectional and stateless
- CAPI supports event deduplication via shared event IDs and richer first-party data payloads
In practice they overlap. Many platforms now offer both, postback for simple use cases, CAPI for richer setups.
Common mistakes
- Firing the postback before the order is committed. Failed orders trigger phantom conversions. Wait for the actual commit.
- Sending postbacks for refunded orders. Most platforms accept refund postbacks too, use them or your conversion data is permanently inflated.
- Hard-coding postback URLs in client-side code. Defeats the security and reliability benefits of server-side firing.
FAQ about Postback
What is a postback?
A postback is a server-to-server signal sent from an advertiser to an ad platform when a tracked event happens. The platform attaches a click ID to outbound URLs. The advertiser fires it back via HTTP when the conversion occurs.
Postback vs CAPI, what is the difference?
Both are server-to-server. Postbacks are simpler (HTTP GET with query parameters, stateless). CAPI is richer (HTTPS POST with JSON, supports event-ID deduplication). Many platforms now offer both.
Why are postbacks used in mobile attribution?
Mobile attribution ran on postbacks long before web tracking caught up. Apple’s SKAdNetwork uses postbacks. Mobile measurement providers like AppsFlyer and Adjust use them too. They work over any HTTP stack and require no SDK.