What Is a Postback URL? S2S Tracking Explained

A postback URL lets an advertiser's server report conversions with a click ID instead of a browser pixel. How S2S tracking works, how to set it up, and how to debug it.

In this article
  1. How a click ID travels from click to conversion
  2. Anatomy of a postback URL
  3. Pixel vs postback vs Conversions API
  4. Step-by-step: setting up S2S postback tracking
  5. Troubleshooting missing conversions
  6. Security: tokens, IP allowlists and deduplication
  7. Set up S2S tracking for your program
  8. FAQ

A postback URL is an endpoint that one server calls to report a conversion to another, which is why the method is called server-to-server (S2S) tracking. When a visitor clicks an affiliate link, the tracking platform assigns a unique click ID. The advertiser stores it, and when the sign-up, sale or deposit happens, its server requests the postback URL with that click ID and the conversion details.

No browser pixel is involved, so the conversion report survives ad blockers, cookie restrictions and events that happen long after the session, such as a first deposit confirmed three days after registration. If you run your own program, our overview of S2S tracking for brands shows how the advertiser side fits together.

How a click ID travels from click to conversion

Every postback depends on one value surviving the whole journey: the click ID. In a typical affiliate setup the sequence looks like this:

  1. Click. A visitor clicks the affiliate's tracking link. The network or tracker logs the click (time, IP, device, affiliate, campaign, sub IDs) and generates a unique click ID.
  2. Landing. The visitor reaches the advertiser's site with the click ID appended to the URL or written to a first-party cookie by a tracking script.
  3. Storage. The advertiser saves the click ID against the session, the user account or the order, ideally in its own database.
  4. Conversion. The visitor registers, buys or deposits, minutes or weeks later, as long as it falls inside the program's cookie duration.
  5. Postback. The advertiser's backend calls the postback URL with the stored click ID and the event details.
  6. Attribution. The network looks up the click ID, credits the right affiliate and campaign, calculates the commission and can relay the conversion to the affiliate's own tracker.

The same journey as three requests (example domains):

1. Click     https://track.example-network.com/click?offer=42&aff=1001&sub1=adset_7
2. Landing   https://brand.example.com/welcome?click_id=8f3c2a91e4b74d0a9c1e5f7b2d6a3c40
3. Postback  https://track.example-network.com/postback?click_id=8f3c2a91e4b74d0a9c1e5f7b2d6a3c40&event=sale&amount=120.00&currency=USD&order_id=ORD-10442

The key difference from cookie-based tracking is step 5. A pixel fires from the visitor's browser and depends on the network's cookie still being readable; a postback fires from the advertiser's server and only needs the click ID the advertiser already saved. That matters because browsers keep tightening storage rules: Safari blocks third-party cookies by default and deletes a site's script-writable storage after seven days of browser use without interaction with that site (WebKit).

Capturing the click ID is still the advertiser's job, but once it is stored server-side, the conversion report no longer depends on what the browser allows.

Anatomy of a postback URL

A postback URL has two parts: a fixed endpoint owned by the receiving system (the network or tracker) and a query string of parameters. The sending system fills each parameter at fire time, usually through tracking macros: placeholders in curly braces, square brackets or hashes that are replaced with real values.

The template a network publishes might look like this:

https://track.example-network.com/postback?click_id={click_id}&event={event}&amount={amount}&currency={currency}&order_id={order_id}

And this is the request that actually reaches the server after substitution:

https://track.example-network.com/postback?click_id=8f3c2a91e4b74d0a9c1e5f7b2d6a3c40&event=deposit&amount=50.00&currency=EUR&order_id=TX-77812
Parameter Required? What it carries Notes
Click ID Yes The ID issued at click time The only field that links the conversion to an affiliate
Event or status Usually Which goal happened: registration, lead, sale, deposit Must match the names the receiver expects
Amount or payout Optional Sale value, or the commission to credit Dot as decimal separator, no currency symbol
Currency Optional ISO 4217 code such as USD or EUR Without it, the receiver falls back to a default
Transaction or order ID Recommended A unique ID for this conversion Enables deduplication and repeat events such as upsells
Token or key Depends A shared secret that authenticates the sender Sometimes placed in the path instead of the query

Parameter names differ by platform. Keitaro, for example, requires subid and status and accepts optional payout, currency and tid (transaction ID) parameters (Keitaro docs). The affiliate section below links to a tracker-by-tracker breakdown.

Three formatting rules prevent most silent failures:

  • URL-encode every value. An order ID like A&B-17 will otherwise split into two parameters.
  • Send numbers raw. Use 49.90, not $49,90.
  • Keep personal data out of query strings. URLs end up in server logs, proxies and analytics tools, so send an internal or hashed customer ID instead of an email address.

Pixel vs postback vs Conversions API

The three methods are easy to confuse because they report the same event. The difference is where the request comes from and who receives it.

Tracking pixel S2S postback Conversions API (e.g., Meta)
Fired from The visitor's browser, on the confirmation page The advertiser's server The advertiser's server or a partner integration
Matching key A cookie or ID read in the browser The click ID stored by the advertiser Event data plus customer parameters
Affected by cookie limits and ad blockers Yes No, once the click ID is stored Less, because delivery is server-side
Receiver Network or tracker Network or tracker Ad platform
Setup effort Paste a snippet Backend change Backend change plus the platform's schema
Delayed or offline events Hard, the user must load the page Yes Yes
Typical use Quick start, simple funnels Affiliate and partner programs Optimizing paid social campaigns

A tracking pixel is the fastest to install but inherits every browser restriction. A postback is the usual choice for paying partners because the advertiser controls the data and can report events that never touch a browser, such as a deposit confirmed by a payment provider's webhook. A Conversions API sends events to an ad platform for optimization; Meta describes its version as a connection between an advertiser's marketing data and Meta's systems (Meta for Developers).

The methods are not mutually exclusive. An advertiser can run a pixel and the Conversions API side by side and let Meta deduplicate them: Meta treats two events as identical when the pixel's eventID matches the server's event_id and the event names match, within 48 hours of receiving the first one (Meta deduplication guide). The affiliate postback runs alongside both, reporting to the partner network rather than to the ad platform.

Step-by-step: setting up S2S postback tracking

Brand side (advertiser)

  1. Capture the click ID on arrival. Read it from the landing URL or let the network's tracking script store it in a first-party cookie. Check that redirects, consent tools and single-page-app routers don't strip the query string.
  2. Persist it server-side. Save the click ID on the user or order record; a nullable column is enough. Webhook-driven events, such as a payment provider confirming a deposit, have no browser session to read a cookie from.
  3. Fire after the event is committed. Send the postback once the registration is saved or the payment is confirmed, not on a button click. Use a short timeout and never block the user's flow if the call fails.
  4. Send the right event and values. The event name decides which commission rule applies (CPL, CPA, RevShare), so registrations and sales or deposits should be separate postbacks. Include the amount, currency, order ID and your internal customer ID.
  5. Test with a real click. Open a live tracking link, complete a test conversion and confirm it appears in the network's reports with the correct amount.

On MassPartner, the tracking script stores the click ID in a first-party cookie named mp_click, and your server reports conversions to a brand-specific endpoint. Only click_id and event are required; amount, currency, order_id and user_id are optional, and user_id is recommended so campaigns set to "first purchase only" can deduplicate commissions across sessions. The campaign and affiliate are resolved from the click ID, so you never send them, and the tracking page in the brand dashboard lists the parameters and includes an installation tester (campaign setup is covered in the platform documentation).

https://masspartner.com/api/postback/YOUR_BRAND_ID?click_id=8f3c2a91e4b74d0a9c1e5f7b2d6a3c40&event=sale&amount=120.00&currency=USD&order_id=ORD-10442&user_id=CUST-881

Affiliate side (publisher)

Affiliates who buy traffic usually run their own tracker and want the network to report conversions back to it, so they can see return on ad spend per ad, placement or keyword.

  1. Generate a click ID in your tracker and append it to the network's tracking link in a sub ID parameter, for example &sub1={clickid}. The token name depends on your tracker.
  2. Register your tracker's postback URL in the network's dashboard, placing the network macro that returns that sub ID in the tracker's click ID parameter.
  3. Choose the trigger. Decide whether the postback fires when a conversion is created, approved or rejected. "Created" gives faster feedback; "approved" keeps reported revenue closer to what you will actually be paid.
  4. Map payout and currency so the tracker records your commission, not the customer's order value.
  5. Run one end-to-end test before sending paid traffic.

Exact URL formats and click ID macros for each tracker are in our guide to sending affiliate conversions to Voluum, RedTrack, Keitaro and Binom.

Troubleshooting missing conversions

When a conversion exists in the advertiser's backend but not in the network or tracker, work through the chain in order:

Click ID capture

  • A redirect, URL shortener or consent tool dropped the query string, so the click ID never reached the landing page.
  • The tracking script isn't on the landing page, or only loads after a consent choice the visitor never made.
  • The click ID was captured on one domain but the conversion happens on another, such as a checkout subdomain, a hosted payment page or an app.

The postback request

  • A macro was sent literally. If your logs show click_id={click_id}, the sender never substituted the placeholder.
  • A required parameter is missing or misspelled, for example clickid instead of click_id.
  • The event name isn't one the receiver recognizes, so the conversion is ignored or paid under the wrong rule.
  • The postback fires from the browser instead of the server and gets blocked, or fires before the order is committed and is never retried.
  • The call fails on TLS, DNS or a timeout. Log the HTTP status and response body of every request.

Receiver-side rules

  • The click ID belongs to a different account, brand or campaign.
  • The campaign is paused, has ended or is outside its schedule.
  • The conversion was treated as a duplicate of an earlier one with the same click and transaction ID.
  • The conversion was recorded but is waiting for approval or a hold period, so it doesn't show in "approved" reports yet.

MassPartner's postback endpoint answers each request with JSON, and failed requests return HTTP 400 with the reason, such as Click not found, Missing required parameters: click_id, event or Campaign is not active. Successful conversions are approved automatically only when the campaign's approval mode allows it and the click's fraud score is below the threshold; otherwise they wait for review. So a postback can succeed while the commission still shows as pending.

Security: tokens, IP allowlists and deduplication

A postback URL is effectively an instruction to pay someone. Anyone who learns the endpoint and a valid click ID can try to forge conversions, so treat it like an API.

  • Secret token or key. Add a long random secret to the path or a parameter and reject requests without it. Keitaro's postback URLs, for instance, contain a unique key that its documentation describes as protection against fake postback requests (Keitaro docs). Rotate the key if the URL leaks in a screenshot or support ticket.
  • Signatures. A stronger option than a static token: the sender computes an HMAC over the parameters and a timestamp with a shared secret, and the receiver rejects mismatches and stale timestamps. This blocks replayed and tampered URLs.
  • IP allowlists. If the sender has fixed outbound IPs, accept postbacks only from them. It is simple and effective but fails silently when the sender changes infrastructure, so pair it with alerting.
  • HTTPS only. A token in a plain HTTP URL can be read in transit.
  • Validate the click. Accept a conversion only if the click ID exists, belongs to the account in the URL and falls inside the attribution window.
  • Deduplicate by transaction ID. Senders retry after timeouts, and refreshed thank-you pages fire twice. Voluum, for example, discards duplicate click IDs by default unless the repeat conversion carries a unique transaction ID (Voluum docs). Apply the same logic on your side: one registration per click and one commission per order ID.
  • Reconcile. Compare postback totals against your own orders on a schedule, and reverse commissions for refunds and chargebacks.

For click-side fraud signals, see our guide to affiliate fraud detection.

Set up S2S tracking for your program

MassPartner gives brands tracking links, a JavaScript tracking script and S2S postbacks in one dashboard, with fraud checks on every click and a conversion approval workflow. Every plan starts with a 7-day free trial. See how S2S tracking for brands works.

FAQ

What is the difference between a postback URL and a tracking pixel?

A tracking pixel fires from the visitor's browser and depends on cookies being readable. A postback URL is called by the advertiser's server with a click ID it stored earlier, so it keeps working when cookies are blocked or the conversion is confirmed by a backend event.

Is S2S postback tracking cookieless?

Only partly. The conversion report itself doesn't depend on cookies, but the advertiser still has to capture the click ID when the visitor lands, often in a first-party cookie, and then store it server-side.

What is a click ID in affiliate marketing?

A click ID is a unique string generated for each click on a tracking link. It is the key that connects a later conversion to the affiliate, campaign and sub IDs recorded for that click.

Can a postback be sent as a POST request?

Yes, when the receiving system supports it. GET requests with query parameters are the most common format, but some platforms also accept POST bodies, so check the endpoint's documentation.

How do I test a postback URL?

Click a live tracking link, complete a real test conversion and confirm it appears with the correct event and amount. Test buttons in network dashboards often send placeholder click IDs the receiver can't match; Keitaro's documentation notes that affiliate networks don't send a real subid in test postbacks.

Glossary terms in this article

About the author

Daniel Reyes

Tracking & Ad-Tech Editor

Daniel covers affiliate tracking and ad-tech for the MassPartner editorial team: postbacks, click IDs, conversion imports, attribution and fraud signals. His guides are checked against official platform documentation and MassPartner's own product docs.

More articles by Daniel →