Skip to main content
When a user completes an offer and we validate the conversion, we send a GET request to your placement’s Postback URL. We send another one if a conversion is later reversed. Your server credits or debits the user and answers with HTTP 200.
Set a postback URL before you go live. Without one, your users can’t be credited automatically.

Your postback URL

Enter a plain URL in the placement’s Settings, for example:
We add the parameters below to it. Query parameters of your own, such as ?token=abc, are kept, as long as they don’t use the same names as ours.

The request

string
The user_id you passed in the offerwall link.
integer
1 to credit the user for a validated conversion, 2 to take the reward back after a reversal.
number
The amount to credit in your currency, based on your exchange rate. Negative on a reversal.
number
Your earnings for the conversion in USD. Negative on a reversal.
string
Unique ID of the conversion. A reversal repeats the transaction_id of the conversion it reverses. Treat it as an opaque string.
string
ID of the completed offer.
string
Name of the completed offer, handy for your users’ reward history.
string
The user’s IP address when they clicked the offer.
string
The user’s two-letter country code when they clicked the offer, for example US.
string
Proof the request came from us. Always check it; see Verify postbacks.
Offers with several goals, such as reaching levels 10, 20 and 30 in a game, send one postback per completed goal. Each goal has its own transaction_id.

Your response

Answer with any 2xx status within 15 seconds. The response body doesn’t matter. Anything else, including a timeout, counts as a failure and we retry automatically.
  • Answer 2xx for a postback you have already processed, so we stop retrying, but don’t credit it again.
  • Answer 403 if the signature doesn’t match.
  • Keep it fast: if crediting takes long, store the postback and finish the work in the background.

A complete handler

Each example checks the signature, applies every transaction_id and status pair only once, and credits or debits the user. reward is negative on a reversal, so adding it to the balance debits the user.
The primary key on transaction_id and status lets you store a conversion and its reversal, and rejects repeats of either: