From CPA Network Postback to Conversions API: Where the Chain Breaks

Every CPA network postback has to survive two handoffs before the ad platform counts the money: first from the network into your tracker, then from your tracker into the platform's Conversions API. Each handoff runs on a written contract of required parameters, and each one has a documented set of ways to tear. This guide walks both contracts hop by hop, catalogs the break points with their exact symptoms, and shows how to test and repair the chain when a conversion stops arriving.

The situation that makes this chain necessary - running offers on pages you cannot tag - is covered in server-side conversions without site access. Here the focus is the plumbing itself.

Two Handoffs, One Conversion

The conversion is a single fact - a user you paid for took an action worth money - but it crosses two organizational boundaries on its way to the platform's optimization:

1. Handoff one: network postback to tracker. The network's server calls your tracker's postback URL, echoing the click identifier it promised to carry and declaring a status. Your tracker matches the call to the stored click.
2. Handoff two: tracker to Conversions API. Your tracker (or an automation acting for it) builds a platform event from the matched conversion and POSTs it to the platform's server-side endpoint.

The two handoffs speak different languages. Handoff one speaks tracker: subid, status, payout. Handoff two speaks platform: event name, event time, hashed user data, action source. The tracker's job is translation - and like any translation, it silently drops whatever one side cannot express. That is where the audit always starts.

Conversions API knowledge lives cluster-wide; this page stays on the chain that feeds it.

Handoff One: The Network Postback Contract

Keitaro's documentation defines the incoming postback URL precisely: the tracker server address, a postback key - "a unique identifier for security and request authentication" - and conversion parameters, taken from Settings, Postback URL. The canonical shape looks like this:

http://your-tracker.example/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE

You copy that URL into the affiliate network's account and map the placeholders to the network's own macros. The parameter that makes or breaks everything is the first one:

Non-standard network parameter names get solved with aliases: Keitaro's Postback URL settings accept replacements, so a network posting clickid=...&profit=... lands in the same fields (Keitaro postback documentation). Binom's postback v2 follows the same pattern with its own token names (Binom postback docs).

One more contract rule matters at scale: re-sending a postback with the same subid but changed parameters overwrites the earlier conversion, while an identical resend does not re-fire the tracker's outgoing S2S - the tracker's own dedup, documented in its S2S postback guide.

Where Handoff One Tears

Keitaro's troubleshooting page lists the failure modes by the exact log entries they produce (Maintenance, Logs, Postbacks):

The subid failure deserves its own warning: it usually originates upstream of the tracker, in the offer link. Keitaro's checklist says to verify that the subid click parameter is correctly passed to the network's offer - for redirect offers through the network's offer parameters, for local offers with a hidden input such as <input type="hidden" name="sub1" value="{subid}" /> - and if the mapping is right and conversions still arrive unmatched, "contact the affiliate network to clarify why the correct subid value is not passed" (postback troubleshooting).

Testing has the same trap in reverse: "affiliate networks do not send a real subid in test postbacks," so a network-side test button proves nothing about matching. The only valid test is a real conversion through your own campaign link.

Handoff Two: From Tracker to Conversions API

After a successful match, the tracker builds the platform event. Translation runs in both directions of the postback: subid becomes the event's identity anchor, status becomes the event name, payout becomes value, and the stored click context - IP, user agent, click ID - becomes the matching data.

What the receiving end demands is documented per platform. Meta requires action_source, event_source_url, and client_user_agent on website events, accepts event_time up to seven days in the past, and fails a whole request over one stale event (Conversions API parameters, using the API). Reddit's Conversions API v3 takes direct server events with its own match-key requirements (direct integration), and deduplicates pixel against server events by conversion ID (event deduplication). TikTok's Events API fills the same slot in TikTok's funnel, with the tracker-side wiring in Keitaro's TikTok integration.

The per-platform wiring has its own guides: Keitaro and Facebook CAPI for Meta, Keitaro postbacks for Facebook and TikTok for the two-platform setup, and Reddit Conversions API setup for Reddit.

What Gets Lost Between the Handoffs

Even with both handoffs technically working, translation loss accumulates:

1. Status model mismatch. Networks carry rich statuses (lead, sale, rejected, rebill, trash); platforms expect a short list of standard event names. The mapping decision - which network status becomes which event - decides what your pixel learns, and a wrong mapping cannot be fixed retroactively because the platform already optimized on it.
2. Timing. Handoff one is near-instant; handoff two inherits its delay plus the platform's acceptance window. A network that confirms sales days after the click spends the platform's seven-day budget on its own latency.
3. Identity. Handoff one is as good as the subid echo; handoff two is as good as the stored click context. A conversion can survive handoff one perfectly and still reach the platform with a match key too thin to attribute - the no-access losses are quantified in the no-access playbook.
4. Value. The network's payout currency and sign conventions (negative payouts for rebills and chargebacks) translate into the event's value and currency fields - or quietly disappear if the delivery layer drops them.

None of these gaps throws an error. They just make your Ads Manager numbers diverge from the network balance, which is the deduplication and discrepancy territory - counting rules, not broken pipes.

Repairing a Torn Chain

A working repair procedure:

1. Find the tear boundary. Postback log empty - the chain is broken at handoff one's input. Log entry present but the platform shows nothing - the tear is in handoff two.
2. Apply the matching fix from the tables above: re-map the subid macro, add the missing status, re-copy the postback key, re-save the URL in the network account.
3. Fix translation losses deliberately: decide the status-to-event mapping and the value rules instead of inheriting defaults.
4. Re-verify with a real conversion through your campaign link - never a network test button - and watch both ends: the tracker log and the platform's test tooling.
5. Walk the whole chain monthly; the postback troubleshooting checklist turns this into a printable routine.

CPA Network Postback to CAPI: Frequently Asked Questions

Sources