Developer documentation

Everything you need, on one page.

Embed the wall, receive the conversion on your server, credit the user. Below is the whole path with copy-paste examples. The deep pages are linked where they add detail.

Quickstart

Three things to do. None of them need an app release.

01 Apply and get approvedCreate a publisher account and submit your site. Applications are read by a person.

02 Copy your keysOnce approved, the Setup page gives you a public key and a secret key, and takes your postback URL.

03 Embed and creditPaste the iframe (or call the Offers API), then credit the user when the postback arrives.

Get a publisher account

Keys and setup

Every placement has its own pair of keys. The public one travels in the iframe URL; the secret never leaves your server — it is what signs the postback.

Key	Where it goes	Notes
site_key	Iframe URL, Offers API	Public. Safe in the browser.
site_secret	Your server only	Signs the postback. Never put it in client code.

One placement, one pair

If you run several sites or apps, create a placement for each. That is what keeps the reporting and the payouts separable.

Embed the wall

The fastest path. Pass your public key and the id you already use for that user — the same value comes back in the postback as subId.

index.html

<iframe
  src="https://newwall.178.105.95.44.nip.io/offer/YOUR_KEY/USER_ID"
  width="100%" height="700"
  frameborder="0" allow="clipboard-write"></iframe>

Step-by-step with the apply and setup screens: integration guide →

Postback

When a user completes an offer we make an HTTP GET to the postback URL you configured, with everything needed to credit them. No client trust, no polling.

Parameter	Description
subId	The user who completed the action — the same id you put in the iframe URL.
transId	Unique id of the transaction. Deduplicate on this.
reward	Amount of your virtual currency to credit.
round_reward	The same amount, rounded to the decimals set for the placement.
payout	Offer payout in USD.
status	`1` add the currency · `2` subtract it (advertiser cancellation, fraud or mistake).
signature	MD5 hash that proves the call came from us.
userIp	The user's IP address.
offer_id / offer_name	Which offer was completed.
country	ISO 2-letter country the lead came from.
uuid	Unique id of the click that produced it.
event_id / event_name	Which event was credited. Empty on single-reward offers.

reward and payout are always positive

A cancellation does not arrive as a negative number: it arrives with status=2. Read the status, not the sign.

Signature

The signature must equal the MD5 of subId + transId + reward + secret. Rebuild it with your own secret and compare before crediting anything.

postback.php

$secret = 'YOUR_SECRET_KEY';   // from the Setup page

$subId     = $_REQUEST['subId']     ?? null;
$transId   = $_REQUEST['transId']   ?? null;
$reward    = $_REQUEST['reward']    ?? null;
$status    = (int) ($_REQUEST['status'] ?? 1);
$signature = $_REQUEST['signature'] ?? null;

// 1 — is it really us?
if (!hash_equals(md5($subId . $transId . $reward . $secret), (string) $signature)) {
    exit('INVALID SIGNATURE');
}

// 2 — already seen? say DUP and we stop retrying
if (Credit::where('trans_id', $transId)->exists()) {
    exit('DUP');
}

// 3 — status 1 adds, status 2 subtracts
$user->addCoins($status === 2 ? -(float) $reward : (float) $reward);
exit('OK');

What to reply

Our server expects one of two plain-text answers:

OK — a new transaction you have just credited.
DUP — you had already credited this transId. We stop retrying it.

We wait up to 60 seconds. On timeout the same transaction is retried up to 5 times over the next few hours, which is exactly why the transId check matters.

Offers API

If you want your own interface instead of our wall, pull the catalogue as JSON and render it yourself. Crediting still happens through the postback above.

GET

GET https://newwall.178.105.95.44.nip.io/api/v1/offers?site_key=publickey&site_secret=secretkey

Parameters, error codes, the full field reference and the top-converting variant: API reference →

Testing

The Setup page has a testing tool that fires a real postback at your endpoint, signed the same way, so you can confirm crediting works before any real traffic arrives.

You answer OK and the balance moves.
The same transId twice: the second one answers DUP and credits nothing.
A status=2 call subtracts instead of adding.

Checklist before going live

The secret is only on your server, never in client code.
The signature is verified on every call.
transId is stored and checked, so nobody is paid twice.
status=2 subtracts.
Your endpoint answers well inside 60 seconds, even under load.

Stuck on something?

Open a ticket from your panel with the transId and we can trace the exact call in our log.