Postbacks (S2S)
A postback is a server-to-server HTTP call that reports a conversion. No browser, no cookies — just one server telling another that something happened. Synaptyx is on both ends: it receives postbacks from CPA networks and sends postbacks to your traffic sources.
Inbound: receiving conversions from a network
When a CPA network approves a lead/sale, it calls your conversion URL. You give the network a URL template; it fills in the real values:
https://trk.yourdomain.com/api/conversion?click_id={clickid}&payout={payout}&status={status}Synaptyx is flexible about the click-ID parameter name — it accepts click_id, cid,
clickid, subid, ref_id, tid, transaction_id, s1, aff_sub,
aff_click_id, and more — so it works with most networks out of the box.
What happens on an inbound postback
Rate-limit & validate
Abusive bursts and replays are throttled so a misbehaving sender can’t flood you.
Authenticate (optional but recommended)
If you set a postback secret on the CPA Network, the call must include &s=<secret>.
You can also restrict to an IP allowlist.
Map the status
The network’s status (numeric or text) is normalized to approved, pending,
declined, or hold.
De-duplicate
Repeat postbacks for the same conversion are ignored, so nothing is counted twice.
Create & attribute
The conversion is created, attributed to the original click, revenue is recorded (for approved), and the fan-out fires.
Failed attempts are logged with a clear reason (missing click ID, click not found, rate-limited, duplicate…) so you can debug a misconfigured network.
The conversion endpoint is built for machine-to-machine calls (networks aren’t browsers), so it’s secured by your optional postback secret, IP allowlist, rate limiting, and duplicate protection rather than a browser-style origin check.
Outbound: reporting conversions to your traffic source
When a conversion is created, Synaptyx can fire a postback to your traffic source’s tracker (e.g. to feed an ad platform’s optimization). You configure the traffic source’s postback URL with macros:
https://source.com/postback?cid={ref_id}&payout={payout}&status={status}Reliable delivery with retries
Outbound postbacks are fire-and-forget with retries, so a slow or flaky endpoint never blocks your conversion recording:
| Behavior | Detail |
|---|---|
| Retries | Failed deliveries are retried automatically with increasing delays. |
| Retryable | Server and network errors. |
| Not retryable | A clearly bad request (it won’t get better). |
| Final failures | Held safely so they can be replayed once your endpoint recovers. |
Outbound calls are sent through safeguards that prevent them from being abused to reach private systems.
Supported macros
Outbound postback templates support the full macro set,
including `{clickid}`, `{ref_id}`, `{payout}`, `{revenue}`,
`{status}`, `{goal}`, `{event}`, `{transactionid}`,
`{country}`, and `{sub1}`–`{sub14}`.
Postback nodes vs. traffic-source postbacks
You can also fire a postback from a S2S Postback node in the visual builder, attached to an Offer — useful when you want a specific callback for a specific offer rather than a blanket traffic-source postback.