Postback vs Conversions API: Two Server Channels With Different Jobs
Two Server-to-Server Channels, Two Different Recipients
The postback vs Conversions API question sounds like a choice between two competing technologies, and that framing is what confuses the setup. Both are server-to-server: no browser, no cookies, no JavaScript. The difference is who talks to whom. A postback is an HTTP request that flies from an advertiser's or affiliate network's server to your tracker's server to report that a conversion happened - Keitaro's documentation defines it exactly this way. The Conversions API is the reverse-facing channel: your server (the tracker, a bridge, or a delivery tool) posts the conversion to the advertising platform so the platform's own attribution sees it.
In a funnel that runs both, the conversion makes two hops on the server side: the network fires a postback to the tracker, and the tracker side then delivers a Conversions API event onward to Meta, TikTok, Reddit, or whichever platform bought the traffic. The general context for why both hops matter is in server-side tracking.
How a Postback Works
Keitaro's documentation gives a precise reference implementation. The postback URL combines the tracker's address, a postback key for authentication, and conversion parameters - a template looks like http://IP/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE. When the request arrives, the tracker looks up the click by subid and validates the status; a request without a status, or with an unknown status that has no mapping, is silently ignored. That silence is why postback troubleshooting usually starts with two questions: did the click ID survive into the URL, and does the status name match what the tracker expects.
The parameter set is deliberately small. Required: subid (which click to credit) and status. Optional: tid for the transaction ID so repeat conversions stack instead of overwriting, payout with the conversion amount, cost, currency, up to thirty extra sub_id parameters, and a return value for the response body. Statuses map to funnel stages - Lead, Sale, Rejected, Registration, Deposit, Trash - which is more granular than what an ad platform's standard event set typically expresses.
How the Conversions API Works
At its core, the Conversions API is the platform's own intake for server events. Meta's version is the reference point: your server posts an event payload with the pixel ID and an access token, the event carries a name, a timestamp no older than seven days, user data hashed with SHA-256, and an event_id so the same conversion arriving from both the pixel and the server does not double-count. The platform uses these events to fuel attribution and optimization - which is exactly the part a postback never touches, because the tracker's database is invisible to the ad platform.
Payload requirements are stricter than a postback's. A postback tolerates a bare query string with two parameters; a CAPI event wants normalized, hashed identifiers and consistent event naming, and the quality of that payload visibly affects match rates and event match quality scores. The failure modes are documented per network, starting with Meta's error codes.
Where Each Channel Sits in an Affiliate Funnel
The standard chain looks like this: the offer page or affiliate network fires the postback to the tracker (hop one), the tracker records the conversion against the click, and a delivery layer transforms that postback into a Conversions API event for the ad platform (hop two). Hops do not share a protocol: hop one speaks the tracker's postback dialect (subid, status, payout), hop two speaks the platform's API dialect (event_name, hashed user_data, event_id). Identifiers need explicit translation - the tracker's click ID maps to the platform's click identifier (like fbclid) that was captured at click time, and the transaction ID becomes the key for preventing duplicate sends of the same event.
That translation layer is where the server-side conversion delivery architecture lives, whether you build it as a script, a tag-server endpoint, or delegate it. MOST does exactly this job - accepts tracker postbacks and delivers properly formatted, deduplicated events to Meta, TikTok, Reddit, Pinterest, Snapchat, and OpenAI; for a single landing with a manual flow, the free Pixel Activator covers the same delivery path.
When a Postback Alone Is Enough - and When You Need CAPI
A postback alone is complete for one job: accounting. Payouts land in the tracker, reports match the network's numbers, and nothing else is required. The channel breaks down the moment expectations shift from "see the conversions" to "make the platform find more of them" - campaign optimization, lookalike seeding, and accurate in-platform reporting all consume platform-side events, and a tracker database feeds none of them.
And the reverse holds: a Conversions API event without a postback means the platform hears about conversions your own tracker never records, and reconciliation becomes guesswork. Funnels that skip hop one lose the ability to reject or adjust conversions after the fact - the status model (Lead, Sale, Rejected) lives on the postback side, and platforms do not offer an equivalent rollback for already-counted events beyond sending new events. That is why mature setups run both channels and keep the deduplication and status-mapping discipline between them.