Postback (S2S) tracking overview

Postback (server-to-server) sends conversions from your affiliate network directly to Wevion's Meta-only postback store. Feeds the postback conversion column in reporting.

Written By Salvatore Sinigaglia

Last updated About 4 hours ago

Postback (server-to-server) sends conversions from your affiliate network directly to Wevion's Meta-only postback store. Feeds the postback conversion column in reporting.

Postback (S2S) tracking overview

Postback is server-to-server conversion tracking. When a conversion happens on your network / tracker side, it calls a public Wevion receiver with the conversion details keyed to your sheet_id. Wevion stores the conversion in its Meta postback store — it does not forward the event on to Meta CAPI / Google / TikTok. The stored conversions feed the switchable postback conversion source in Ads Manager. Bypasses browser limitations like iOS ATT opt-out, ad blockers, cookie deprecation, because the data comes from your server.

Who is this for

Affiliate marketers, performance buyers running tracker-based funnels (Keitaro/Voluum/RedTrack), anyone whose conversion attribution dropped after iOS 14.5 (browser pixel less reliable).

What "S2S" means

S2S (Server-to-Server) = no browser involved. Instead of:

User browses → Browser pixel fires → Ad platform receives via browser

You have:

User browses → Tracker/network server logs conversion → Sends HTTP request to Wevion → Wevion stores the conversion

The conversion travels server-to-server (network → Wevion), never relying on the user's browser to send the signal. Wevion stores it against your sheet_id and surfaces it as the postback conversion source in reporting.

Why use postback

Browser pixel limitationHow postback solves it
Ad blockers silence pixel JSServer-side bypasses blockers
iOS 14.5+ ATT opt-out reduces trackingServer-side unaffected
3rd-party cookie deprecationNo cookies needed (server has the data)
Off-site conversions (affiliate funnels, app installs via tracker)Server-side is the only option
Customer abandons before pixel loadsServer already logged via your backend

For affiliate funnels especially: the conversion often happens on the offer's site (not yours), so you can't install pixel there — postback is the only way.

Wevion's postback endpoints

The public receiver external networks call is separate from the authenticated management endpoints you use inside Wevion.

Public receiver — verified vs apps/backend/src/routes/meta-postback-conversion.route.ts:

EndpointMethodPurpose
/meta/postback/conversionGETPublic, unauthenticated. Called by external affiliate networks to report a conversion (sheet_id in the query identifies your account)

Authenticated management — verified vs apps/backend/src/routes/api/postback.route.ts (all GET):

EndpointMethodPurpose
/api/v1/postback/configGETYour postback URL template + total conversion stats
/api/v1/postback/conversionsGETList your stored postback conversions (server-side paginated / filtered)
/api/v1/postback/conversions/currenciesGETList currencies present in your postback conversions

The postback service: apps/backend/src/services/meta-postback-conversion.service.ts. Repository: apps/backend/src/repositories/meta-postback-conversion.repository.ts. Duplicate deliveries are collapsed via a unique constraint on (sheet_id, transaction_id).

How it works end-to-end

1. User clicks your ad on Meta   ↓2. Lands on tracker URL (Keitaro / Voluum / etc.) with click_id   ↓3. Tracker logs the click + redirects to your offer   ↓4. User converts on the offer (purchase, signup, install)   ↓5. Offer fires a postback to your tracker/network with conversion details   ↓6. Network sends the postback to Wevion's receiver URL   (URL configured in the network's Postback URL field, with your sheet_id)   ↓7. Wevion receives at GET /meta/postback/conversion   ↓8. Wevion stores the conversion against your sheet_id   (idempotent on sheet_id + transaction_id)   ↓9. The stored conversion appears as the "postback" conversion source   in Ads Manager reporting

This chain captures conversions server-side with zero browser dependency. Note that Wevion stores the conversion for reporting — it does not re-send the event to Meta CAPI / Google / TikTok.

Macros / variables in postback URLs

Your Wevion postback receiver URL looks like:

https://api.wevion.ai/meta/postback/conversion?  sheet_id={your_sheet_id}  &transaction_id={transaction_id}  &payout={payout}  &currency={currency}  &campaign_id={campaign_id}  &adset_id={adset_id}  &ad_id={ad_id}

The {...} parts get replaced by your tracker/network with actual values when firing the postback. Key parameters:

  • sheet_id — your Wevion account identifier (identifies who the conversion belongs to)
  • transaction_id — the conversion ID (used with sheet_id for idempotency)
  • payout — conversion revenue
  • currency — 3-letter currency code (USD, EUR, etc.)
  • campaign_id / adset_id / ad_id — Meta attribution keys

Different trackers use different macro syntaxes for these values:

  • Keitaro: {click_id}, {revenue}, {currency}
  • Voluum: ${click_id}, ${payout}, ${currency}
  • RedTrack: {clickid}, {sum}, {currency}

See your tracker's postback documentation for the exact syntax to use.

Setup walkthrough

Detailed step-by-step in com-110 postback setup.

When to use postback vs pixel

Use postback whenUse browser pixel when
Affiliate marketing (funnel touches offer site)Direct e-commerce on your own site
App installs (tracker → MMP → ad platform)Lead-gen forms on your site
Off-site conversion eventsHigh-value conversions where dedup matters
Privacy-conscious users (iOS, ad blockers)Generally for redundancy alongside CAPI
Server-side data already collectedBrowser-side data only

Best: use both with deduplication via event_id matching. See com-111 postback vs pixel.

What the receiver stores

The postback receiver records the conversion details passed in the query string, keyed to your sheet_id:

  • transaction_id — the conversion identifier (used for idempotency together with sheet_id)
  • payout + currency — conversion revenue
  • campaign_id / adset_id / ad_id — Meta attribution keys
  • received_at — when Wevion stored it

Duplicate deliveries with the same (sheet_id, transaction_id) are collapsed and not double-counted.

Security

  • The receiver is a public, unauthenticated endpoint (GET /meta/postback/conversion); the sheet_id in the query identifies your account
  • HTTPS endpoint
  • Idempotent on (sheet_id, transaction_id) — redelivered conversions are not double-counted

What you'll see

Healthy postback setup:

  • Your stored conversions are listed via GET /api/v1/postback/conversions (server-side paginated + filterable)
  • In Ads Manager, the switchable postback conversion source shows the stored conversion counts + revenue
  • New conversions appear shortly after your network fires the postback

Common questions

  • "How do I know if my network is sending postback?": check your stored conversions list (/api/v1/postback/conversions) or the postback conversion column in Ads Manager. If empty, the network isn't sending (or the URL / sheet_id is wrong).
  • "Network sends but nothing shows in Wevion": verify the receiver URL is exactly /meta/postback/conversion and that sheet_id matches your account.
  • "Can I use postback without a tracker (Keitaro etc.)?": yes — if your backend logs conversions, you can call Wevion's receiver URL directly from your own server.
  • "Does postback forward to Meta CAPI?": no. The postback store keeps conversions for Wevion reporting; it does not re-send events to Meta CAPI / Google / TikTok. For server-side CAPI sends, see the pixel/CAPI setup (meta-105).

FAQ

What is postback (S2S) tracking in Wevion?

Postback is server-to-server conversion tracking. When a conversion happens on your network / tracker, it calls a public Wevion receiver (GET /meta/postback/conversion) with the conversion details keyed to your sheet_id; Wevion stores the conversion. Because the signal travels server-side, it never relies on the user's browser. It is a Meta-only store and is not re-sent to ad platforms.

Why does Wevion postback beat a browser pixel for iOS and ad blockers?

Postback is unaffected by iOS 14.5+ ATT opt-outs, ad blockers, and third-party cookie deprecation, because the conversion data comes from your server, not the browser. Browser pixels are silenced by ad blockers and reduced by ATT opt-outs. For affiliate funnels, where the conversion happens on an offer site you cannot pixel, postback is the only way to capture the conversion server-side.

Can I use Wevion postback without a tracker like Keitaro?

Yes. If your own backend logs conversions, you can call Wevion's receiver URL directly from your server instead of using a tracker such as Keitaro, Voluum, or RedTrack. Wevion receives the event at GET /meta/postback/conversion and stores it against the sheet_id you pass, keyed by transaction_id for idempotency.

Does Wevion postback replace or feed Meta CAPI?

Neither. Postback is a standalone Meta-only conversion store used for Wevion reporting — it does not fire Meta CAPI events on your behalf, and it does not forward to Google or TikTok. If you need server-side CAPI sends, set those up through the pixel/CAPI flow (meta-105).

What does the Wevion postback receiver store?

The receiver records the parameters passed in the query string — transaction_id, payout, currency, and the Meta attribution keys campaign_id / adset_id / ad_id — all keyed to your sheet_id, plus a received_at timestamp. Duplicate deliveries sharing (sheet_id, transaction_id) are collapsed and not double-counted.