How to Set Up Postback Tracking (Step-by-Step Guide)

Postback tracking is the backbone of modern CPA marketing, and setting it up correctly is the difference between flying blind and having full visibility into every conversion your campaigns generate. Also known as server-to-server (S2S) tracking, postback URLs allow CPA networks and advertisers to notify your system in real time when a conversion occurs — without relying on cookies, browser redirects, or client-side JavaScript. If you run an offerwall, rewards site, or any CPA campaign infrastructure, understanding postback tracking is non-negotiable.

This guide walks you through everything you need to know about postback tracking: what it is, how it compares to pixel tracking, how to configure it step by step, how to test it, how to secure it, and how to troubleshoot common problems. Whether you are a publisher setting up your first campaign or a developer building a conversion tracking system, this guide covers the full process.

What Is Postback Tracking?

A postback (also called a server-to-server callback or S2S postback) is an HTTP request sent from one server to another to communicate that a specific event has occurred — typically a conversion. In CPA marketing, the flow works like this:

1. A user clicks your tracking link, which contains a unique click ID and optional sub-ID parameters.
2. The CPA network records the click and redirects the user to the advertiser's offer page.
3. The user completes the required action (signup, install, purchase, etc.) on the advertiser's site.
4. The advertiser confirms the conversion to the CPA network.
5. The CPA network fires an HTTP GET or POST request (the postback) to a URL you have specified, passing back the click ID, conversion details, and payout amount.
6. Your server receives the postback, processes it, and takes appropriate action — logging the conversion, crediting a user, updating a dashboard, or triggering a notification.

The key concept is that postbacks happen server-to-server. The user's browser is not involved. This makes postback tracking far more reliable than client-side tracking methods, especially in an era of aggressive cookie blocking, ad blockers, and browser privacy restrictions.

Postback Tracking vs. Pixel Tracking: Key Differences

Before diving into setup, it is important to understand why postback tracking is preferred over pixel (client-side) tracking for CPA campaigns.

Feature	Postback (S2S) Tracking	Pixel (Client-Side) Tracking
How it works	Server sends HTTP request to your server	JavaScript or image pixel fires in user's browser
Cookie dependency	None — fully cookieless	Relies on cookies to match clicks to conversions
Ad blocker impact	Not affected	Blocked by most ad blockers
Browser privacy	Not affected by ITP, ETP, or cookie restrictions	Severely impacted by Safari ITP, Firefox ETP, Chrome changes
Accuracy	95-99%+ accuracy	60-80% accuracy (declining)
Cross-device tracking	Works if click ID is passed through	Does not work across devices
Setup complexity	Requires server endpoint	Simple JavaScript snippet
Delay tolerance	Handles delayed conversions well	May fail if user closes browser before pixel fires
Fraud detection	Easier to validate with IP checks, tokens	Harder to validate, susceptible to spoofing

The verdict is clear: postback tracking is the industry standard for CPA marketing in 2026. The IAB Tech Lab has published measurement guidelines that increasingly favor server-to-server methods for their accuracy and privacy compliance. Pixel tracking still has a role in some display advertising and retargeting contexts, but for conversion tracking in affiliate and performance marketing, S2S postbacks are the way to go.

Step 1: Understand Your Tracking Architecture

Before configuring anything, map out your tracking architecture. There are several common setups depending on your role:

Publisher Direct Setup

If you are a publisher running campaigns and want to track conversions on your end (for example, to update a dashboard or credit a user on your rewards site), you need to provide your CPA network with a postback URL that points to your server.

Third-Party Tracker Setup

If you use a tracking platform like Voluum, BeMob, RedTrack, or Keitaro, the tracker acts as an intermediary. The CPA network fires the postback to your tracker, and the tracker records the conversion and optionally forwards it to your own server.

Offerwall or Rewards Platform Setup

If you operate an offerwall or GPT site, postbacks are how you know when to credit users with points or rewards. Your server must receive the postback, identify the user, and credit their account in real time.

Regardless of your specific setup, the core mechanics are the same: you provide a URL endpoint, the network sends conversion data to it, and your system processes the data.

Step 2: Gather Your Tracking Parameters

Every CPA network uses a set of tokens (also called macros or placeholders) that get dynamically replaced with actual values when the postback fires. You need to know which tokens your network supports. Here are the most common ones:

Token	What It Contains	Example Value	Required?
{click_id}	Unique identifier for the click	abc123def456	Yes
{offer_id}	The ID of the offer that converted	1042	Yes
{payout}	The payout amount for this conversion	3.50	Yes
{transaction_id}	Unique ID for this specific conversion event	txn_789xyz	Yes
{sub1}	First sub-ID you passed in the click URL	user_12345	Depends on use case
{sub2}	Second sub-ID	campaign_a	Optional
{sub3}	Third sub-ID	landing_v2	Optional
{datetime}	Timestamp of the conversion	2026-03-15 14:23:01	Optional
{ip}	IP address of the converting user	203.0.113.42	Optional
{status}	Conversion status (approved, pending, reversed)	approved	Optional

Important: Token names vary between networks. RevBoost uses the token format shown above, but other networks may use different names like {aff_sub}, {clickid}, or #payout#. Always check your specific network's documentation for their exact token names.

Understanding Sub-IDs

Sub-IDs are custom parameters you append to your tracking links when sending traffic. They pass through the network's system untouched and come back to you in the postback. This is how you identify which user, campaign, ad creative, or traffic source generated a conversion.

For offerwall operators, sub1 is critical — it typically carries your user's ID so you know which account to credit when the postback fires. For media buyers, sub-IDs help attribute conversions to specific campaigns and creatives.

Step 3: Build Your Postback URL

Your postback URL is the endpoint on your server that will receive conversion notifications. It combines your server's domain, endpoint path, and the network's token placeholders as query parameters.

Basic Postback URL Structure

Here is a typical postback URL template:

https://yoursite.com/api/postback?click_id={click_id}&offer_id={offer_id}&payout={payout}&tx_id={transaction_id}&sub1={sub1}&sub2={sub2}&status={status}

For Offerwall / Rewards Sites

If you run a rewards platform and need to credit users, your postback URL might look like this:

https://yoursite.com/api/postback?user_id={sub1}&offer_id={offer_id}&payout={payout}&tx_id={transaction_id}&secret=YOUR_SECRET_KEY

In this case, {sub1} carries the user's ID from your platform, which you passed when the user clicked the offer link.

For Third-Party Trackers

If you use Voluum, BeMob, or another tracker, they provide you with a pre-formatted postback URL. You copy that URL into your CPA network's postback settings. The tracker will then receive the postback and record the conversion in its dashboard.

Best Practices for Postback URL Construction

• Always use HTTPS — Use an SSL-secured endpoint. Most networks require it, and it prevents data from being intercepted in transit.
• Include a secret token — Add a static secret parameter to your URL (e.g., &secret=a8f3k2m9) so your server can verify the request came from an expected source.
• Include the transaction ID — This is essential for deduplication. Without it, you cannot reliably prevent double-crediting from duplicate postbacks.
• URL-encode special characters — If any of your static parameters contain special characters, URL-encode them to prevent parsing errors.
• Keep it clean — Only include parameters you actually need and will process. Extra unused parameters add complexity without value.

Step 4: Configure the Postback in Your CPA Network

Now you need to enter your postback URL in your CPA network's platform. The exact steps vary by network, but the process is generally similar.

Global vs. Offer-Level Postbacks

Most networks allow you to set postbacks at two levels:

• Global postback — Fires for every conversion across all offers. Set this if you want all conversions routed to the same endpoint (common for trackers and offerwall platforms).
• Offer-level postback — Fires only for conversions on a specific offer. Use this if you need different handling for different offers, or if you only want postbacks for certain campaigns.

Configuration Steps (General Process)

1. Log in to your CPA network's publisher dashboard.
2. Navigate to the tracking or postback settings section. This is often under "Settings," "Tracking," or "Postback URLs."
3. Select whether you want a global postback or an offer-specific postback.
4. Paste your postback URL template (with the network's tokens) into the URL field.
5. Select the HTTP method — usually GET, though some setups use POST.
6. Choose which events should trigger the postback (approved conversions, pending conversions, reversed conversions, or all).
7. Save the configuration.

Configuration in RevBoost

In the RevBoost publisher dashboard, navigate to Settings > Postback URLs. You can set a global postback URL that fires for all offers, or configure individual postbacks at the campaign level. RevBoost supports both GET and POST methods, and you can choose to receive postbacks for approved conversions only or for all status changes (including reversals).

Step 5: Build Your Server-Side Postback Handler

Your postback handler is the server-side code that receives and processes incoming postback requests. Here is what it needs to do:

Core Logic Flow

1. Receive the request — Parse the incoming query parameters (click_id, offer_id, payout, transaction_id, sub-IDs, etc.).
2. Validate the request — Check the secret token, verify the source IP, and ensure all required parameters are present.
3. Check for duplicates — Look up the transaction ID in your database. If it already exists, reject the postback to prevent double-crediting.
4. Process the conversion — Log the conversion, credit the user (if applicable), update your dashboard, or trigger any downstream actions.
5. Return a response — Send back an HTTP 200 OK status to acknowledge receipt. Most networks expect a 200 response and will retry on failure.

Example Handler Logic (Pseudocode)

Here is a simplified pseudocode outline for a postback handler:

// 1. Parse parameters
click_id = request.params["click_id"]
offer_id = request.params["offer_id"]
payout = request.params["payout"]
tx_id = request.params["tx_id"]
user_id = request.params["user_id"]   // from sub1
secret = request.params["secret"]

// 2. Validate secret
if secret != "YOUR_SECRET_KEY":
    return 403 Forbidden

// 3. Validate required fields
if not all([click_id, offer_id, payout, tx_id]):
    return 400 Bad Request

// 4. Check for duplicate
if database.exists("postbacks", tx_id):
    return 200 OK (already processed)

// 5. Log the conversion
database.insert("postbacks", {
    click_id, offer_id, payout, tx_id, user_id,
    created_at: now()
})

// 6. Credit the user (for rewards sites)
if user_id:
    points = calculate_points(payout)
    database.increment("users", user_id, "balance", points)

// 7. Return success
return 200 OK

Important Implementation Details

• Use asynchronous processing for heavy operations — If crediting a user involves sending notifications, updating leaderboards, or triggering other systems, queue those tasks asynchronously. The postback handler should respond quickly (within 1-2 seconds).
• Log everything — Store the raw postback request (URL, headers, IP) in a log table. This is invaluable for debugging and dispute resolution.
• Handle both GET and POST — Some networks use GET, others use POST. Build your handler to accept both methods.
• Return 200 for duplicates too — If you receive a duplicate postback, still return 200. Returning an error may cause the network to keep retrying.

Step 6: Test Your Postback Setup

Never assume your postback is working correctly. Test it thoroughly before going live with real traffic.

Method 1: Manual Test with cURL or Browser

Simulate a postback by manually calling your endpoint with test parameters:

curl "https://yoursite.com/api/postback?click_id=test123&offer_id=1&payout=3.50&tx_id=test_txn_001&user_id=testuser&secret=YOUR_SECRET_KEY"

Verify that your server returns 200 OK, the conversion is logged in your database, and the test user is credited (if applicable).

Method 2: Network Test Tool

Many CPA networks have a built-in postback testing tool. RevBoost provides a test postback feature in the publisher dashboard that sends a simulated postback to your URL with sample data. Use this to verify the full round trip.

Method 3: Live Test Conversion

The most reliable test is a real conversion. Complete a test offer yourself (if the network allows it) or ask your account manager to trigger a test conversion. This validates the entire flow from click to postback.

Testing Checklist

• Does the postback arrive at your server? (Check server logs.)
• Are all parameters populated correctly? (No empty or malformed values.)
• Is the conversion logged in your database?
• Is the correct user credited with the correct amount? (For rewards sites.)
• Does your deduplication work? (Send the same postback twice — only one should be processed.)
• Does your secret validation work? (Send a postback with a wrong secret — it should be rejected.)
• Does your server respond within the expected timeout? (Usually 5-10 seconds max.)

Step 7: Secure Your Postback Endpoint

An unsecured postback endpoint is an invitation for fraud. Anyone who discovers your URL could send fake postbacks to credit accounts or corrupt your data. Here are essential security measures:

IP Whitelisting

Only accept postback requests from your CPA network's known server IP addresses. RevBoost and most networks publish their postback server IPs. Configure your firewall or application logic to reject requests from any other IP.

Secret Token Validation

Include a static secret parameter in your postback URL that only you and the network know. Your handler should reject any request where the secret does not match. Rotate this secret periodically.

Transaction ID Deduplication

Store every transaction ID you process. Before crediting a conversion, check if that transaction ID already exists. This prevents double-crediting from duplicate postbacks, network retries, or replay attacks.

Payout Validation

Cross-check the payout amount in the postback against the expected payout for that offer. If an offer pays $3.50 but the postback claims $350.00, flag it for manual review.

Rate Limiting

Implement rate limiting on your postback endpoint. If you suddenly receive thousands of postbacks per second from an unexpected source, your rate limiter should throttle or block the traffic.

HTTPS Only

Never accept postbacks over plain HTTP. Always use HTTPS to encrypt the data in transit, including your secret token and user identifiers.

Troubleshooting Common Postback Issues

Even with careful setup, postback issues arise. Here are the most common problems and how to fix them:

Postbacks Not Firing

• Postback URL not saved — Double-check that the URL is correctly entered in your network dashboard and saved.
• Offer-level override — Some offers may have their own postback settings that override your global URL. Check offer-level configurations.
• No conversions yet — If there have been no actual conversions, there will be no postbacks. Verify that the offer is getting clicks and conversions in the network dashboard first.
• Wrong event type selected — You may have configured the postback for "approved" conversions only, but the conversion is still in "pending" status.

Postbacks Firing but Not Being Received

• Server is down — Check that your server is running and the endpoint is accessible from the public internet.
• Firewall blocking — Your firewall may be blocking requests from the network's IP addresses. Add the network's IPs to your whitelist.
• SSL certificate issues — An expired or misconfigured SSL certificate will cause HTTPS requests to fail. Verify your certificate is valid.
• DNS issues — If your domain's DNS is not resolving correctly, the network's servers cannot reach your endpoint.

Postbacks Received but Data Is Wrong

• Mismatched tokens — You may be using the wrong token names for your network. Double-check the documentation for exact token syntax.
• Missing sub-IDs — If sub-ID values come back empty, verify that you are passing them correctly in your click tracking URLs.
• URL encoding issues — Special characters in parameter values can cause parsing problems. Ensure proper URL encoding.

Duplicate Postbacks

• Network retries — If your server responds slowly or returns an error, the network may retry the postback. Implement deduplication using the transaction ID.
• Multiple postback configurations — Check that you do not have both a global and offer-level postback set, which could result in double-firing.

Advanced Postback Configurations

Multi-Network Postback Routing

If you work with multiple CPA networks, you might receive postbacks from several sources at the same endpoint. Add a parameter to identify the source network:

https://yoursite.com/api/postback?network=revboost&click_id={click_id}&offer_id={offer_id}&payout={payout}&tx_id={transaction_id}&sub1={sub1}

Your handler can then apply network-specific validation (different IP whitelists, different token names) based on the network parameter.

Conversion Status Updates

Some networks send multiple postbacks for the same conversion as its status changes — pending, approved, reversed. Handle each status appropriately:

• Pending — Log the conversion but do not credit the user yet (optional — some sites credit immediately).
• Approved — Credit the user and record the conversion as finalized.
• Reversed / Rejected — Deduct the previously credited amount from the user's balance. This is critical for maintaining accurate financials.

Postback Forwarding (Daisy Chaining)

In some setups, you may need to receive a postback and then forward it to another system — for example, from your tracker to your rewards platform, or from your server to a third-party analytics tool. Build your handler to optionally fire an outgoing HTTP request after processing the incoming postback.

Postback Tracking and Compliance

Postback data often contains user identifiers and behavioral signals. Handle this data responsibly:

• Data retention — Define how long you store postback data. Delete or anonymize data you no longer need.
• Access control — Limit access to postback logs and conversion data to authorized personnel.
• Privacy regulations — If you operate in regions subject to GDPR, CCPA, or similar regulations, ensure your postback data handling complies with applicable privacy laws. The FTC's guidance on data collection and consumer protection also applies to tracking and attribution systems.
• User transparency — If you run a rewards site, your terms of service should explain that conversion tracking is used to credit rewards.

Monitoring and Maintenance

Once your postback tracking is live, ongoing monitoring ensures it stays reliable:

Set Up Alerts

Configure alerts for abnormal conditions — for example, if your postback volume drops to zero for more than an hour (possible server issue), or if it spikes dramatically (possible fraud or misconfiguration).

Check Discrepancies Regularly

Compare your postback conversion counts against the network's dashboard at least weekly. Small discrepancies (1-3%) are normal due to timing and processing differences. Large discrepancies indicate a tracking problem that needs investigation.

Keep Server Uptime High

If your server is down when a postback fires, you miss the conversion. Most networks retry failed postbacks a few times over a period of hours, but they do not retry indefinitely. Aim for 99.9%+ uptime on your postback endpoint.

Update Postback URLs When Migrating

If you change your server, domain, or endpoint path, update your postback URLs in every CPA network immediately. Keep the old endpoint running for at least a few days to catch any delayed postbacks in transit.

Getting Started with Postback Tracking on RevBoost

If you are a RevBoost publisher, setting up postback tracking is straightforward:

1. Log in to your RevBoost dashboard.
2. Navigate to Settings > Postback URLs.
3. Enter your postback URL with the appropriate RevBoost tokens.
4. Select the events you want to receive (approved, pending, reversed).
5. Use the Test Postback button to verify your endpoint is receiving data correctly.
6. Go live and start tracking conversions.

Not a RevBoost publisher yet? Apply here — it takes less than five minutes, and our account managers will help you configure postback tracking for your specific setup.

Postback tracking is a foundational skill in CPA marketing. Once you have it set up and tested, you have a reliable, accurate, and secure system for tracking every conversion your campaigns generate. That visibility is what allows you to optimize, scale, and grow your earnings with confidence.

Related Resources

• Pixel vs Postback Tracking Explained
• What Is a Sub-ID?
• How to Integrate an Offerwall API
• Best CPA Networks for App Developers
• What Is EPC (Earnings Per Click)?