What Is a Postback URL? How Server-Side Tracking Works for Offerwalls

A postback URL lets ClixWall tell your server when an offer is credited or reversed. Your server uses that event to update the user's balance. This guide explains the current publisher callback fields and the checks that keep rewards accurate. For the full setup, keep the ClixWall integration reference open alongside it.

What is a postback URL?

A postback is a server-to-server request to an endpoint you configure on your publisher website. The user does not need to keep the offerwall open for your server to receive a confirmed conversion. The callback includes the user identifier you supplied when they opened the Wall, an amount to credit, a transaction ID, and a status.

The postback tells your system about a ClixWall event. It does not replace the advertiser or offer partner's conversion checks. Only credit a reward after your endpoint receives and processes the event.

How the ClixWall flow works

1. Your app opens the Wall with a publisher API key and a stable user ID, for example /wall?api=YOUR_API_KEY&user=USER_ID.
2. The user chooses an offer and completes its requirements.
3. After the conversion is confirmed, ClixWall calls the postback URL saved for that publisher website.
4. Your server finds the user, records the transaction ID, and applies the credit. If a later reversal arrives, it adjusts the same user's balance.

The offerwall integration guide covers the iframe, WebView, and Offers API paths that lead to this callback.

Configure the URL and fields

Add a publicly reachable URL in your publisher website settings. These placeholders are supported by the current postback reference:

https://yourapp.example/clixwall-postback/YOUR_PRIVATE_TOKEN?user_id={user_id}&user_payout={user_payout}&publisher_payout={publisher_payout}&transaction_id={transaction_id}&status={status}

The reference also lists offer_id and offer_name where available. Do not make an offer name mandatory for every callback.

Standard offer and task callbacks, including the dashboard's test callback, use form-encoded HTTP POST. Some survey-provider callbacks use HTTP GET with values in the configured URL. Put the core placeholders in the URL as shown, and have your endpoint accept both methods. Parse query values and form data without double counting a field that appears in both places.

Credit users safely

Build your handler around these checks:

1. Require HTTPS and compare the private URL token with a value stored on your server.
2. Require a known user ID, a valid numeric user payout, a transaction ID, and a recognized status. Do not use publisher_payout as the user's reward.
3. Process the event and balance change in one database transaction. Enforce uniqueness for the conversion ID and event direction so duplicate delivery cannot credit twice.
4. Apply reversals to the original user's balance. An offer or task reversal may reuse the original transaction ID with a reversal status, so do not discard it merely because the ID exists.
5. Log the event ID, status, and processing outcome for support and reconciliation, while redacting the private URL token and user data you do not need.

ClixWall's offer and task callbacks may use numeric status values such as 1 for a credit and 2 for a reversal; survey callbacks may use text such as completed. Test the events your integration receives and map only recognized values to balance changes. An unknown status should not create a reward.

Return a successful HTTP response only after the event has been durably processed or recognized as a duplicate. Keep a way to reconcile your records with conversion history in the publisher dashboard; do not assume an automatic retry schedule.

Test and troubleshoot

On your publisher website page, open Settings → Test to send a sample conversion to your configured URL. The dashboard shows the HTTP status your endpoint returned. Use a test user and verify that your balance and transaction record changed once; an HTTP 200 alone does not prove crediting worked.

If nothing arrives, check the public URL, HTTPS certificate, server logs, and whether your handler accepts form-encoded POST. If a survey callback fails, also check GET support and the URL placeholders. If rewards duplicate or reversals fail, inspect how you key events in your database.

For the current parameter list and integration examples, use the publisher integration documentation. If you are new to the product, start with ClixWall for publishers.