Postbacks & tracking
Offerwall tracking that never loses or double-counts a conversion
Every click carries a signed ID. Every postback is verified, stored raw and queued before we answer. Every conversion is unique by transaction ID, and every publisher postback is signed and retried for 72 hours.
01
Click
Signed click ID, screened at the edge
GET /c/off_1187?user=u_381
02
Partner
The user completes the offer
Everflow · offer 1187
03
Postback
Verified, stored raw, queued, 200
POST /pb/p/src_ev · txn_8f2c
04
Reward
Signed postback to the publisher
+1,200 Coins → u_381
Sample data
The money path
From click to credited user
Step 1: Click
The user taps an offer. We issue a click ID signed with HMAC-SHA256 that binds your network, the app, the user and the offer, then redirect to the partner in one hop.
Step 2: Partner postback
The partner calls your connection's postback URL with the click ID and its transaction ID. We check the key, store the raw request, queue it and answer 200.
Step 3: Conversion
A background job verifies the click signature, applies fraud rules and records the conversion once. Retries and repeated partner calls are recognised as duplicates.
Step 4: Publisher postback
We call the publisher's postback URL with the user ID, reward, payout and a signature hash, retrying with backoff until their server answers 2xx.
Details that matter when money is on the line
Tamper-proof click IDs
Click IDs are signed tokens valid for 90 days. A forged, altered or expired ID is rejected before any conversion is written.
Short IDs where needed
For partners that limit sub-ID length, such as impact.com, we pass a short ID and keep the signed token at the edge for the postback.
Learn moreExactly-once conversions
Conversions are unique per source and transaction ID, so a partner firing the same postback twice credits the user once.
Reversals handled
When a partner reverses a conversion, or you reverse it in the console, the publisher receives a postback with negative reward and status rejected.
Raw request archive
Every partner and manual postback is stored exactly as received, with method, URL, IP, user agent and body, before it is processed.
Retries for 72 hours
Failed publisher postbacks are retried after 1 minute, doubling each time up to once an hour, for 72 hours from the conversion.
Publisher postback
Macros your publishers already know
Publishers put macros in their postback URL, in {curly} or [BRACKET] style. The hash lets them verify each call came from your network.
1https://publisher.example/postback?uid={user_id}&amount={reward}&txn={transaction_id}&status={status}&sig={hash}2 3hash = sha256(user_id + offer_id + transaction_id + postback_secret)Goals and payouts
Multi-event offers and partner-reported payouts
Partner postbacks can carry a goal and a payout. A goal maps to the offer's matching event, so installs, registrations and level-ups each pay their own reward. When the partner reports a payout, that amount is used; otherwise the goal's or offer's payout applies. Publisher share and the app's currency rate are applied in integer micros, so amounts never drift through floating-point rounding.
See the full macro listTop offers
Last 7 days
| Offer | Region | Clicks | Conv. | Revenue |
|---|---|---|---|---|
| Kingdom Clash | US | 12,480 | 842 | $9,264 |
| Word Garden | GB | 8,110 | 517 | $3,102 |
| Pocket Farm | DE | 6,392 | 401 | $2,807 |
| Survey Sprint | CA | 5,870 | 1,126 | $1,689 |
| Cashback Plus | AU | 3,214 | 203 | $1,218 |
Conversions
18.2k↑ 12%
vs last week
Sample data
- click ID lifetime
- 90 days
- publisher postback retry window
- 72 hours
- retry backoff
- 1 min to 1 h
- publisher response timeout
- 10 s
Frequently asked questions
Something else on your mind? hello@launchofferwall.com
What happens if my publisher's server is down?
We keep retrying: after 1 minute, then 2, 4 and so on up to once an hour, until their server responds with a 2xx or 72 hours have passed. Every attempt's status and response is recorded.
Do you support GET and POST postbacks from partners?
Yes. Partner and manual postback endpoints accept GET query strings and POST bodies as JSON or form data.
How are pending conversions handled?
Each partner connection maps the partner's statuses to approved, pending or reversed. By default pending conversions are not credited until approved; you can choose to credit them immediately.
Are held conversions sent to publishers?
Not until you approve them. Conversions held by fraud rules wait in a review queue; approving one sends the publisher postback.