A server-to-server (S2S) postback is a backend-to-backend HTTP request that delivers conversion event data from your servers to ad networks, MMPs, or attribution platforms. Instead of relying on the mobile SDK in the app to fire conversion events (which requires the user to have the app open), S2S postbacks fire from your servers whenever events happen — independent of whether the user is currently using the app.
How S2S postbacks work
- User completes a conversion event (subscribe, purchase, milestone) — recorded in your backend.
- Your backend fires an HTTP POST to the MMP / ad network's S2S endpoint with: user ID (or device ID, hashed), event name, event timestamp, revenue (if applicable), other metadata.
- The receiver (MMP or ad network) deduplicates against existing data and processes the event for attribution / optimization.
- The event flows downstream to ad-network optimization algorithms (Meta, TikTok, Google) for bidding signals.
The key difference from SDK-based attribution: the SDK fires events from the device when the app is open. S2S fires from your server independent of the device state.
Why S2S is more reliable than SDK-based
- Not affected by ad-blockers — some users run network-level ad-blockers that intercept SDK calls. S2S bypasses this entirely.
- Doesn't require the app to be open — purchase confirmations from Apple's StoreKit, subscription renewals, server-side webhook events can fire S2S even when the user isn't in the app.
- More accurate for delayed events — subscription renewals, trial-to-paid conversions, monthly billing events all happen async; S2S can fire them in real time.
- Better for sensitive events — events involving payment data or user identity are safer to fire server-side.
- Easier deduplication — your backend can ensure each event fires exactly once; SDK-based events can fire multiple times if sessions overlap.
Common use cases
- Subscription / IAP event firing — Apple's StoreKit Server-Side Notifications and Google Play's Real-Time Developer Notifications feed your backend, which fires S2S postbacks to MMPs.
- Conversion API integrations with Meta, TikTok, Google — server-side event firing for ad-platform optimization, especially post-ATT when SDK-only events are noisier.
- Custom event tracking — events that happen entirely server-side (admin operations, async user actions).
- Webhook integrations — third-party services (Stripe, Shopify, billing platforms) firing events to your backend, then onward to MMPs.
- Validation / fraud detection — server-side validation prevents the client from spoofing events.
Implementation considerations
- Major MMPs all support S2S — AppsFlyer, Adjust, Singular, Branch, Kochava expose S2S endpoints.
- Ad networks support varies — Meta Conversions API, TikTok Events API, Google Conversion Tracking all support S2S. Smaller networks may not.
- Identifier hashing — when firing user identifiers via S2S, hash emails / phones (SHA-256 standard) before sending. Required by major networks.
- Idempotency keys — use event-unique IDs to prevent double-firing if your retry logic fires the same event multiple times.
- Rate limiting — major receivers have rate limits; batch events when possible.
- Latency tolerance — S2S can be slightly slower than SDK-based; networks tolerate a few seconds of delay but not hours.