What is an S2S postback? Conversion data from server to server
An S2S postback is a server-to-server message reporting an event, commonly a conversion. An advertiser, partner network or tracking service can send it to another system. It moves information about an action; it does not independently prove who caused the action or whether that customer will be valuable.
Follow the event, not just the request
In a common affiliate flow, a referral creates a click identifier, the product records a qualifying action and a server sends the identifier with event information to a tracker. The tracker matches it to a known referral and may notify another system. Each connection has its own sender, receiver and data contract.
Decide which product record establishes the event. A purchase-button click is not a settled payment, and a trial is not a paid subscription. Choose the event that supports the business decision, then define how corrections and later changes reach the receiving system. This is part of end-to-end analytics, not just a URL setting.
Agree identifiers, values and update rules
Use the recipient's current documentation for required fields, method, authentication and accepted responses. Do not paste one network's parameter names into another network's template. For example, current Keitaro documentation requires subid and status for conversion processing; a missing or unmapped status can leave a request unrecorded.
Keep the click identifier distinct from the transaction or event identifier. One referral can produce several purchases, while a retry can describe the same purchase again. Specify which message creates a new record and which updates an existing one, including refunds or rejected actions.
Define the amount and currency as well. Affiliate commission, order revenue and product contribution are not interchangeable values. Record the event time separately from processing time where the integration supports it, so delayed delivery does not silently change the period being analyzed.
Make retries safe and failures visible
Authenticate messages using the mechanism the provider supports, protect credentials and use HTTPS. Keep secret-bearing URLs out of public pages and shared screenshots, and redact sensitive values in logs. A transaction identifier helps with duplicate handling but is not proof that the sender is authorized.
A timeout can occur after a receiver has already processed an event, so a retry must not create a second commission or purchase. For systems you build, use durable processing records and an idempotent operation: handling the same event again should not repeat its business effect. Stripe's webhook documentation illustrates why signatures, duplicate handling and retry behavior must be considered together.
Follow the API's response and retry rules rather than retrying every error the same way. Temporary unavailability or rate limiting may be retryable; an invalid field usually needs correction. Keep failed deliveries available for investigation and controlled replay. An HTTP success status alone is not acceptance evidence if the API reports processing problems in the body or a later log.
Respect the limits of server-side measurement
A server message does not depend on a browser pixel at the moment it is sent, but the earlier journey may still depend on permitted identifiers, browser storage or app integration. Missing identifiers, mismatched attribution windows and cross-device use can leave an event unattributed. Server-side delivery does not recover information that was never collected or cannot lawfully be used.
Apple's AppTrackingTransparency rules apply to the defined tracking activity, not merely to whether the final request comes from a server. A hashed email is not a substitute for required ATT permission. Apple's privacy-preserving AdAttributionKit provides a different attribution route; its reports should not be treated as unrestricted user-level click-ID callbacks.
Choose the supported integration for the actual web or app environment. An MMP can help manage mobile measurement, but not every platform or event requires the same MMP-based arrangement. Document coverage and uncertainty instead of promising that S2S eliminates data loss.
Accept the integration through a controlled journey
Use a test environment or a provider-approved test process so checks do not create payable conversions or affect live bidding. Create a valid test referral, complete the intended action and reconcile the source record with the received event, amount and status.
Repeat the same event, send an invalid identifier, simulate an authorization failure and check the permitted retry or correction path. Test a subsequent purchase and a refund separately. If browser and server events both report the same action, verify the platform's deduplication rules.
Then inspect an independently authorized example through the same path and confirm that monitoring catches missing or rejected messages. Agree who owns failures after release. A green request in a console is not enough if the product record and final report disagree.
FAQ
Is a postback the same as a webhook?
The terms overlap in marketing integrations: both can describe one system notifying another about an event. Read the actual data contract because method, authentication and update behavior vary.
Can S2S work without a separate tracker?
Yes, when the sending and receiving systems support a direct integration. Someone still needs to own event definitions, identifiers, security, retries and reconciliation.
Does a 200 response prove the conversion was counted?
Not universally. Check the API's response semantics and the receiving system's processing record, including event status and attribution.
Does S2S tracking remove the need for consent?
No. Collection, use and sharing must follow the applicable privacy requirements and platform rules regardless of the transport mechanism.
Sources
- Keitaro: current postback processing and parameters
- Stripe: receiving and verifying webhook events
- Apple: user privacy and data use
Discuss your product's next step
I help define product priorities, plan launches and investigate where users drop out.
