S2S postback tracking is how conversion and lead outcomes travel back from advertisers and buyers to the system that sent the traffic. A click can reach an offer, but until the buyer reports what happened, your platform cannot tell whether that click became an accepted lead, a rejection or a conversion. Without that signal, routing is blind: you keep sending traffic without knowing which destinations are working.
A postback connects the click to its outcome using an ID passed between systems. That makes it a core part of affiliate link tracking and lead operations. It also gives your team a way to act on buyer feedback: pause a capped destination, route around a rejection pattern or send more traffic to an offer that is accepting and converting.
The setup is not complicated, but small mismatches can break it. The click ID must survive every redirect, the buyer must call the right URL, and both sides need to agree on what each status means. Here is how to connect the pieces.
How S2S postback tracking works
A typical server to server tracking flow looks like this:
- A click gets a click ID. Your tracking platform creates a unique ID when someone clicks an affiliate link or enters a lead flow. The ID is recorded with details such as campaign, source, geo and device.
- The ID is passed to the offer or buyer. Your redirect or lead distribution integration adds the click ID to the destination URL or request. The destination needs to save it with the click or lead record.
- A conversion or lead status happens. The buyer or advertiser processes the event. It might be an accepted insurance lead, a rejected finance application, a sale from a nutra offer or a sweepstakes conversion.
- The buyer’s server calls your postback URL. The callback includes the original click ID and an outcome. It may also include payout, a transaction ID or other fields your setup uses.
- Your platform matches and records the event. It looks up the click ID, attaches the status and value to the original traffic record, and updates reporting.
- A partner postback fires, if configured. Your platform can pass the outcome to an affiliate, network or another system using that partner’s required parameter names and status mapping.
That final step matters when you work with multiple partners. Your buyer might send “accepted,” while an affiliate expects “approved.” Map statuses deliberately instead of forwarding raw values and hoping each system interprets them the same way.
In a lead-generation setup, the same logic can sit alongside a lead distribution API. An API can submit a lead to a buyer and return an immediate response; a postback can report a later outcome, such as whether the buyer accepted or converted it. For a reliable buyer API integration, define which events arrive in the API response and which arrive later by postback.
Postback URL anatomy
A postback URL is an endpoint that receives the outcome data. Your tracking platform provides the base URL and its accepted tokens. The buyer fills those tokens with values from its system when it sends the callback.
Example: https://tracker.example/postback?click_id={click_id}&status={status}&payout={payout}&sub1={sub1}&sub2={sub2}&txid={transaction_id}
This is a template, not a universal format. One platform may expect click_id; another may use a different token name. Confirm the receiving platform’s parameters, then map them to the buyer’s available fields. If the buyer uses a different status vocabulary, agree on the values before launch.
| Parameter | Purpose | Common mistake |
|---|---|---|
| click_id | Matches the outcome to the original click or lead. | Passing a different ID, truncating it, or dropping it in a redirect. |
| status | Reports the event, such as accepted, rejected or converted. | Using values the receiving platform does not recognize or mapping acceptance as conversion. |
| payout | Reports the amount associated with the event. | Sending a formatted value with a currency symbol when the platform expects a number. |
| sub-IDs | Carry attribution details such as source, placement or publisher ID. | Overwriting a sub-ID or assuming it is the click ID. |
| transaction ID | Identifies the buyer’s event and can help detect duplicate callbacks. | Leaving it out when available or treating it as a substitute for the click ID. |
Use sub-IDs for values you will actually use in reporting or partner reconciliation. Keep the click ID dedicated to matching. If you also pass personal lead data, follow your partner agreements and collect only what the flow requires.
Test with a real click path before sending meaningful volume. Check that the click ID reaches the destination, trigger a test outcome, and verify that the platform records the correct status and payout. Then confirm that any partner postback contains the expected IDs and mapped values. A successful HTTP response alone does not prove the event matched the right click.
Pixel vs S2S postback vs API
| Method | Reliability | Cookie dependence | Setup effort | Best for |
|---|---|---|---|---|
| Pixel | Can miss events if the page does not load, the browser closes or scripts are blocked. | Often relies on browser-side identifiers or cookies, depending on the implementation. | Usually simple to place, but browser behavior needs testing. | Basic browser events when you control the confirmation page. |
| S2S postback | Server sends the event directly; matching still depends on correct IDs and callback handling. | Does not require a third-party browser cookie for the callback. | Requires ID passing, URL configuration and status mapping. | Affiliate conversions and buyer outcomes, including delayed lead statuses. |
| API | Supports structured requests and responses; reliability depends on implementation, retries and error handling. | Does not inherently depend on browser cookies. | More coordination and development than a basic callback. | Lead submission, buyer integrations and workflows that need richer data exchange. |
For affiliate and lead-generation operations, S2S is the default for reporting outcomes because the buyer can notify your platform from its server without relying on a conversion page loading in the user’s browser. It is not automatic attribution: if the click ID is lost, the postback cannot repair the match. And if the buyer never sends the callback, your platform still has no outcome to record.
Use pixels when you need a simple browser event and can control the page. Use an API when you need to submit leads, exchange structured data or handle responses as part of the workflow. Use S2S postbacks to return outcomes to the system that tracked or routed the traffic. For a broader approach to tracking with less reliance on browser storage, see cookie-light tracking.
Once those signals arrive, they can inform the next routing decision. Hyperone can use buyer outcomes alongside rules for caps, source, geo and destination availability, so traffic can move when a buyer stops accepting leads rather than continuing into a dead end.
Three postback flows you need
A complete s2s postback tracking setup carries outcomes between the parties that need them. The exact path depends on whether you are tracking an offer conversion, reporting back to a publisher or distributing leads to buyers.
Advertiser to network: conversions
When an advertiser records a conversion, its server calls your network’s postback URL with the click ID and conversion details. Your platform uses the click ID to match the event to the original visit, then records the status, payout and any transaction ID.
Agree on the event definition before launch. A submitted form, approved application and funded loan are different outcomes. If the advertiser reports a lead as converted at submission but your team expects approval, your reports and optimization decisions will not line up.
Network to publisher: partner postbacks with sub-IDs
After matching an outcome, the network can send a partner postback to the publisher that referred the click. Include the publisher’s click ID and the sub-ID values used to identify a campaign, placement or creative. Those values help the publisher see which traffic produced the outcome without exposing unnecessary personal information.
Keep parameter names and status values consistent across campaigns. If one offer sends “approved” and another sends “sale” for the same event, document the mapping so the publisher can interpret both correctly.
Buyer to lead distributor: accepted, rejected, returned
For lead generation, the buyer or buyer CRM needs to send a clear disposition to the distributor. Common statuses include accepted, rejected and returned. A lead distribution API or buyer API integration can carry those outcomes, while a callback or postback URL may be enough for a simpler setup.
Define when each status is final and what information accompanies it. For example, a rejection reason such as duplicate, out of area or invalid contact can help you diagnose quality issues and make better routing decisions.
Using buyer statuses to drive routing
Do not treat postbacks as reporting-only data. Rejections and returns should lower a source’s priority for the buyer when your rules indicate a quality problem. Acceptance should inform buyer caps and help determine whether traffic can keep flowing to that destination.
Use reason codes where available. A lead rejected as out of area may point to a geo rule that needs fixing; repeated invalid-contact rejections may justify reducing that source’s priority. A returned lead can mean the buyer found a later issue, so make sure your team distinguishes it from an initial rejection.
Say a buyer caps at 200 leads a day. If accepted leads are approaching the cap, your distribution rules can send the next eligible lead to another available buyer instead of continuing to deliver to a capped destination. If the buyer rejects a particular source at a higher rate, you can reduce that source’s priority for that buyer while keeping it eligible elsewhere. Set up buyer caps and fallback routing around the statuses and limits that matter to your campaigns.
Make sure the callback arrives soon enough to be useful. A status that reaches your system hours after delivery can still help with reporting, but it may be too late to guide the next routing decision.
Testing and troubleshooting
Test the whole chain before sending live volume. A successful server response does not prove that the click matched, the status mapped correctly or the partner received the right event.
- Test a click end to end. Create a test click, pass its ID through the offer or buyer flow, trigger a test outcome and confirm it appears against the right record.
- Check macros. Verify that each system replaces its click ID and other macros with real values. A literal token in the received URL usually means the macro was unsupported or mapped incorrectly.
- Check duplicate transaction IDs. Send the same event twice in a test. Confirm your system deduplicates it or flags it instead of counting the conversion twice.
- Verify time zones and status mapping. Compare event timestamps across systems and confirm that accepted, rejected and returned values map to the intended internal statuses.
- Test retries. Simulate a temporary receiving error and check whether the sender retries. Agree how retries work so a delayed callback does not create duplicate outcomes.
- Review logs. Check the outgoing URL, response code, request time and matched click or lead ID. Keep enough detail to diagnose failures without storing more personal data than you need.
- Alert on postback silence. Monitor whether callbacks arrive as expected. A sudden stop can point to a broken integration, expired credentials or a change on the buyer’s side.
Where Hyperone fits
Hyperone brings routing and outcome feedback into the same operating loop. Buyer and CRM statuses can arrive through callbacks and API connections, then feed the next routing decision. That means accepted, rejected and converted outcomes can inform how eligible traffic is handled.
Caps, destination availability and fallback rules act before delivery. If a buyer is capped or unavailable, the configured rules can direct the lead to another eligible destination instead of sending it into a dead end. Intelligent Hubs route each click or lead against your rules, while UAD Manager can shift traffic toward better-performing offers and reroute when a destination fails.
Hyperone plans start at $499 per month. Review pricing to see the available plan details.
FAQ
What is an S2S postback?
An S2S postback is a server-to-server message that reports an event, such as a conversion or lead status, to another platform. It typically includes an identifier that lets the receiving system match the event to the original click or lead.
Is S2S more accurate than a pixel?
S2S tracking does not depend on a browser loading a pixel, so it avoids some browser and cookie-related gaps. It still depends on correct IDs, event definitions and integration setup; a misconfigured postback can report the wrong result or fail to match an event.
What parameters does a postback need?
At minimum, include the click or lead ID and the event status. Depending on your reporting and settlement needs, add a transaction ID, payout, timestamp, rejection reason or agreed sub-IDs.
How do I test a postback URL?
Send a test event using a known click or lead ID, then verify the response and confirm that the event appears on the correct record with the expected status. Check logs for unresolved macros, duplicate events, timestamp differences and failed retries.
Loading...
