Integration flow

At a high level, this is how traffic and rewards move through LootHQ:

1. 1

   User opens your app or site

   You
2. 2

   Your app loads the LootHQ wall

   You

   iframe, script embed, modal, or hosted link, always with your sub_id

3. 3

   User clicks an offer on the wall

   LootHQ

   LootHQ records the click, then redirects to the advertiser

4. 4

   User completes the offer at the advertiser

   Offer network

   install, sign-up, purchase…

5. 5

   The advertiser/network posts the conversion back to LootHQ

   Offer network

   the tracking link is ours, so we always see it first. This is also the moment YOUR wallet is credited in full (see “When you earn” below)

6. 6

   LootHQ credits the user in LootHQ Coins

   LootHQ

   1 USD of payout = 1,000 coins, minus your placement margin; coins drive the wall's leaderboards and prizes

7. 7

   The completion is approved → LootHQ fires your postback

   LootHQ

   {points} arrives here: the amount to credit, already in your currency

8. 8

   Your backend credits the user and shows the completion

   You

Quickstart: wall in 5 minutes

Everything you need to get a hosted wall live, in order, with the exact things to copy. You need one thing before you start: a placement id (step 1 gets you one).

1. 1Create a placement. Dashboard → Placements → New placement → integration type Hosted Wall. Copy its placement id; the snippets below call it YOUR_PLACEMENT_ID.
2. 2Embed the wall. Paste this where the wall should render, filling in both placeholders:
   Script embed (recommended)Copy

   <div id="loothq-wall"></div>
   <script
     src="https://www.loothq.net/wall.js"
     data-placement-id="YOUR_PLACEMENT_ID"
     data-sub-id="{USER_ID}"
     data-container="loothq-wall"
   ></script>
   <!-- Replace YOUR_PLACEMENT_ID with the id from Dashboard → Placements, and
        render {USER_ID} server-side as the signed-in user's STABLE id. -->

   data-sub-id must be a stable id for the signed-in user, unique across all your placements. It is the id your postback will echo back as {user_id}, so it decides who you credit. Prefer an iFrame or a hosted link? Both work identically; the script tag just wires the resize and click plumbing for you.

3. 3Save your postback template. In Settings → Publisher Settings, save this as your Postback URL (swap in your own domain, path and a real secret for YOUR_SECRET; the {macros} stay exactly as written; we fill them in):
   Default postback templateCopy

   https://your-site.com/postback?key=YOUR_SECRET&user_id={user_id}&tx={transaction_id}&points={points}&payout={payout}&currency={currency}&offer_id={offer_id}&offer_name={offer_name}&status={status}&event={event_id}

   Your endpoint credits the user {points} (already in your currency) and returns HTTP 200. Saving warns you, without blocking, if the template is missing {status} or {offer_id}, or if you have no reversal URL yet. Full handler samples are in Postbacks.

4. 4Run the Integration check. Open Dashboard → Integration check and press Run. One click verifies your saved URLs, the attribution macros, and a real delivery to each endpoint that writes no delivery, conversion, stat or ledger row. Every failing row comes with the concrete fix.
5. 5Fire a test. On the same Settings page, run Test delivery in the Postback Tester and confirm your endpoint answers 200. Run it twice: it reuses the same {transaction_id} on purpose, so the second run proves your duplicate check works. Then go live and watch clicks, conversions and revenue in the dashboard.

const user = await db.Users.findById(user_id);
if (!user) {
  return res.status(200).send("unknown user");   // not 404
}

When you are ready for reversal handling in code (recommended before launch), add the separate reversal URL; see Handling reversals. Prefer to render offers in your own UI instead of embedding the wall? Start at the Offers API quickstart.

Hosted link

The simplest integration, and the only genuinely zero-code one, is to send users to your hosted LootHQ offerwall by URL. One link: no JavaScript, no iframe, works in webviews and email. We handle tracking, device detection, and localization for you.

https://www.loothq.net/wall?placement_id=YOUR_PLACEMENT_ID&sub_id={USER_ID}

iFrame

Use an iFrame to keep users inside your own layout while LootHQ handles the offerwall content.

<iframe
  id="loothq-wall"
  src="https://www.loothq.net/wall?placement_id=YOUR_PLACEMENT_ID&sub_id={USER_ID}"
  width="100%"
  height="700"
  frameborder="0"
  scrolling="no"
  allow="clipboard-write"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-popups-to-escape-sandbox"
  style="border: none; width: 100%; min-height: 700px; border-radius: 12px;"
></iframe>

<script>
  window.addEventListener('message', function (e) {
    var frame = document.getElementById('loothq-wall');
    // Only act on messages that actually came from the wall iframe you
    // embedded: check e.origin before touching e.data. Never trust a
    // postMessage's origin implicitly, and never reply with '*'.
    if (!frame) return;
    var wallOrigin;
    try { wallOrigin = new URL(frame.src, window.location.href).origin; } catch (err) { return; }
    if (e.origin !== wallOrigin) return;
    if (!e.data) return;
    // The wall asks whether a host will open offers on its behalf. Answer, or
    // it opens them itself, which your sandbox may block.
    if (e.data.type === 'loothq:wall-ready' && e.source) {
      e.source.postMessage({ type: 'loothq:host-ready' }, wallOrigin);
    }
    // Auto-resize iframe to fit wall content
    if (e.data.type === 'loothq:wall-height' && frame) {
      frame.style.height = Math.max(e.data.height, 500) + 'px';
    }
    // Open offer links in a new tab (required when iframe has sandbox restrictions)
    if (e.data.type === 'loothq:open-url' && e.data.url) {
      window.open(e.data.url, '_blank', 'noopener,noreferrer');
    }
  });
</script>

<!-- Prefer not to hand-roll this? Drop in https://www.loothq.net/wall.js instead; it does all
     of the above (and the modal) for you. See the Script section. -->

We recommend a dedicated "Earn" or "Offerwall" page with a minimum height of 650–800px. You can wrap the iFrame in your own navigation and branding.

Content-Security-Policy: frame-src https://www.loothq.net;

Script

One tag, and we manage the frame. The script mounts the same canonical wall URL as the iFrame method, then does the plumbing the hand-rolled version asks you to write yourself. This is the embed the Quickstart recommends.

<div id="loothq-wall"></div>
<script
  src="https://www.loothq.net/wall.js"
  data-placement-id="YOUR_PLACEMENT_ID"
  data-sub-id="{USER_ID}"
  data-container="loothq-wall"
></script>
<!-- Replace YOUR_PLACEMENT_ID with the id from Dashboard → Placements, and
     render {USER_ID} server-side as the signed-in user's STABLE id. -->

<script src="https://www.loothq.net/wall.js"></script>
<script>
  // e.g. from your "Earn coins" button:
  document.getElementById("earn-btn").addEventListener("click", function () {
    LootHQ.open("YOUR_PLACEMENT_ID", getCurrentUserId());
  });
</script>

Content-Security-Policy: script-src https://www.loothq.net; frame-src https://www.loothq.net;

When to pick which: iFrame means you manage the frame: sizing, placement, and the short message listener. Script means we manage the frame: the tag mounts it, sizes it, and handles offer opening, with modal mode when you want an overlay. Both render the same wall from the same canonical URL.

Setting the wall URL after login

A companion pattern for the iFrame method, not an integration method of its own: leave the iframe's src unset and fill it in client-side once you know who the user is.

const userId = getCurrentUserId(); // your logic
const placementId = "YOUR_PLACEMENT_ID"; // from publisher dashboard → Placements

const wallUrl = "https://www.loothq.net/wall"
  + "?placement_id=" + encodeURIComponent(placementId)
  + "&sub_id=" + encodeURIComponent(userId);

document.getElementById("loothq-wall").src = wallUrl;

This pattern is useful if you render your app client-side or need to inject the wall URL after authentication.

Conversion postbacks (server-to-server)

You save a template URL in Settings → Publisher Settings. When a conversion is approved, LootHQ replaces the {macros} below with real values and calls your URL server-to-server. You choose the param names; just point each one at the macro you want.

https://your-site.com/postback?key=YOUR_SECRET&user_id={user_id}&tx={transaction_id}&points={points}&payout={payout}&currency={currency}&offer_id={offer_id}&offer_name={offer_name}&status={status}&event={event_id}

Start from that exact template, including {offer_id} and {status}. They cost you nothing and you will want both the first time you reconcile: without {offer_id} your reporting can't say which offer paid, and without {status} your handler has nothing to assert on. The placeholder in the Settings field shows this exact template; copy it in and save (the field itself starts empty). Settings checks this for you at save time: it warns (it never blocks the save) when your template is missing {status} or {offer_id}, or when you have saved a primary URL with no reversal URL alongside it.

// Example: Node.js / Express (plain JS, runs as-is under `node`)
// The param names below are the ones YOU chose in your template URL.
app.get("/postback", async (req, res) => {
  const { user_id, tx, points, payout, offer_id, currency, status } = req.query;
  const event = req.query.event || ""; // the conversion's goal id; empty on prize redemptions

  // 0) Auth – your template URL hard-codes &key=...; reject anything without it
  if (req.query.key !== process.env.LOOTHQ_POSTBACK_SECRET) {
    return res.status(403).send("forbidden");
  }

  // 1) Basic sanity checks
  if (!user_id || !tx) {
    return res.status(400).send("missing params");
  }

  // 2) Idempotency – credit each (tx, event) pair exactly once. On wall and
  //    Offers API conversions alike, tx is the CLICK id and repeats for
  //    every goal of a multi-goal offer; only the pair is unique per
  //    credit. On a prize redemption, event is "" and tx alone is unique,
  //    so the pair degrades to tx. For strict safety under concurrent
  //    duplicates (two retries landing at once), also add a UNIQUE INDEX on
  //    the (tx, event) columns; a findOne-then-create check alone still has
  //    a race window.
  const existing = await db.Conversions.findOne({ tx, event });
  if (existing) {
    return res.status(200).send("already processed");
  }

  // 3) Confirm the user belongs to a real account
  const user = await db.Users.findById(user_id);
  if (!user) {
    return res.status(200).send("unknown user");
  }

  // 4) Credit the user.
  //    Hosted wall → {points} is ALREADY in your currency (coins x your rate).
  //                  Credit it as-is. Do NOT credit {payout}, which is USD.
  //    Offers API  → no coins; {payout} is USD, convert it yourself.
  //    Test for "" and not for null: a macro we don't substitute on this
  //    channel arrives PRESENT AND EMPTY, so `points != null` is true on an
  //    Offers API postback and Number("") would credit 0.
  const amount = points !== undefined && points !== ""
    ? Number(points)
    : usdToYourCurrency(Number(payout));

  await creditUser(user_id, amount);

  // 5) Store the conversion for reporting
  await db.Conversions.create({
    tx,
    event,
    user: user_id,
    credited: amount,
    payoutUsd: payout != null ? Number(payout) : null,
    currency: currency || "USD",
    offerId: offer_id || null,
    status: status || "approved",
  });

  return res.status(200).send("ok");
});

Dedupe keys, per channel

The single most expensive class of integration bug is deduping on the wrong key: too weak and retries double-credit, too strong and legitimate credits are silently dropped. This is the whole truth in one table.

• On the primary URL, the pair is always safe. Prize redemptions send an empty {event_id}, so storing the ({transaction_id}, {event_id}) pair degrades to the transaction id alone there, so one dedupe rule covers every placement type you will ever run.
• On conversions, the pair is required. {transaction_id} is the click id on both integration types, and a milestone (CPE) offer credits once per goal on one click: each goal repeats the transaction id and changes the event id. Dedupe on the transaction id alone and goals 2..n are silently discarded.
• Retries never mint new identities. Every automatic retry and every manual Resend of a delivery reuses the exact same {transaction_id} and {event_id} as its first attempt, so the pair you stored keeps matching.
• Reversals dedupe on {event_id} alone. On that channel it is a per-delivery UUID, while {transaction_id}is the original conversion's id and repeats. See Handling reversals.

When you earn

Your LootHQ wallet is credited the full listed payout for that conversion the moment it is approved, for both Hosted Wall and Offers API placements (each goal of a multi-goal offer credits separately as it lands). There's no proration and no waiting on the user.

• The postback is about your user, not your wallet. The approval-time postback tells you what to credit the user in your own currency. It has no effect on your LootHQ wallet; that is settled separately, at the same approval.
• Coins are a score, not a debt. A user's coin balance on the wall drives leaderboards and prizes. Nothing about it delays, reduces, or claws back what you're owed.
• Only an explicit reversal claws back. A genuine reversal (advertiser rejection, chargeback, fraud, void) is the one thing that debits your wallet. See Handling reversals below for exactly how that's delivered.

Users see earned coins instantly, but some categories and new accounts hold coins pending for a short window before they count as available. See Pending and available coins. That window gates only the user's coin display on the wall; it never delays your postback, which fires at approval regardless, and it never delays or reduces your wallet credit.

Track your running balance any time in Publisher Dashboard → Earnings.

Pending and available coins

Coins are credited to the user instantly and visibly the moment a conversion is approved. The wall always shows them right away, split into available (cleared) and pending(clearing soon). Some offer categories and brand-new accounts carry a short clearing window; logged-in users clear faster. The window gates only the user's coin display on the wall. It never touches your side: your postback fires at approval regardless, and your wallet is paid in full at approval regardless.

Clearing windows vary by offer category. A user's trust tier(built from account age, history, and a clean reversal record) shortens them over time, and a verified login shortens them immediately, which is the reason to prompt sign-in. Coins credited on a hosted wall count toward the user's lifetime and leaderboard totals immediately; only availability is gated.

Handling reversals

Your primary postback URL is approvals-only and never carries a reversal or a negative. That promise is permanent. A reversal is netted from your unpaid balance, always, on every account; the balance can dip negative and is recovered from future earnings, never billed. Reversals are delivered on their own channels. Pick what suits you:

https://your-site.com/reversal?key=YOUR_SECRET&user_id={user_id}&tx={transaction_id}&event={event_id}&coins={coins}&points={points}&payout={payout}&reason={reason}&status={status}

// ONE handler for both channels. Save the SAME base URL in BOTH Settings
// fields; the payload's {status} says which channel is calling:
//   Postback URL : https://your-site.com/postback?key=…&user_id={user_id}&tx={transaction_id}&points={points}&payout={payout}&offer_id={offer_id}&status={status}&event={event_id}
//   Reversal URL : https://your-site.com/postback?key=…&user_id={user_id}&tx={transaction_id}&points={points}&payout={payout}&offer_id={offer_id}&status={status}&event={event_id}&reason={reason}
app.get("/postback", async (req, res) => {
  if (req.query.key !== process.env.LOOTHQ_POSTBACK_SECRET) {
    return res.status(403).send("forbidden");
  }
  const { user_id, tx, reason, status, points, payout } = req.query;
  const event = req.query.event || "";

  // A macro we don't substitute on a given channel arrives PRESENT AND EMPTY
  // ("", with the param still there), never missing. So "points ?? payout" and
  // "points != null" both pick the empty string and quietly credit 0.
  const has = (v) => v !== undefined && v !== "";

  // Branch on {status}: it is "approved" on every primary-URL delivery and
  // "reversed" on every reversal-URL delivery, with no third value. Do NOT
  // branch on whether `event` is set: it is also set on approvals (the
  // goal id there). And what does NOT work at all, and what a first
  // integration usually assumes, is waiting for a negative payout on the
  // primary URL. It never arrives.
  if (status === "reversed") {
    // ---- reversal ----
    // Dedupe on {event_id}: on THIS channel it is a fresh UUID per delivery.
    // NOT on tx: on a reversal, tx is the ORIGINAL conversion's id, so it
    // repeats for every reversal of that conversion and every retry of this
    // one.
    if (await db.Reversals.findOne({ event })) {
      return res.status(200).send("already reversed");
    }
    await db.Reversals.create({ event, tx, user: user_id, reason: reason || "unknown" });

    // {points}/{payout} carry the FULL value the approval postback told you
    // to credit: {points} in your currency on wall conversions, 0 on Offers
    // API conversions (no coin layer, so take {payout} in USD instead).
    // Take back exactly that amount. Your own wallet is settled by us
    // either way (see "When you earn").
    const undo = Number(points) > 0
      ? Number(points)
      : usdToYourCurrency(Number(payout));
    if (undo > 0) await debitUser(user_id, undo);
    return res.status(200).send("ok");
  }

  // ---- approval: the only thing the primary URL ever sends ----
  // WHAT TO CREDIT depends on the placement, and the payload tells you which:
  //   hosted wall / prize → {points} is ALREADY your currency. Credit as-is.
  //   Offers API          → no coin step, so {points} is empty and {payout}
  //                         is USD. Convert it yourself.
  const amount = has(points)
    ? Number(points)
    : usdToYourCurrency(Number(payout));

  // IDEMPOTENCY: the (tx, event) pair, unique per credit on every channel.
  // Wall and Offers API conversions alike: tx is the CLICK id and repeats
  // for every goal of a multi-goal offer; event (the goal id) is what
  // separates them, so keying on tx alone would drop every goal after the
  // first. Prize redemptions: tx is unique by itself and event is "", so
  // the pair degrades to tx.
  if (await db.Conversions.findOne({ tx, event })) {
    return res.status(200).send("already processed");
  }
  await db.Conversions.create({ tx, event, user: user_id, credited: amount, status });
  await creditUser(user_id, amount);
  return res.status(200).send("ok");
});

Worked example, end to end

One user, one offer, every request you would actually receive, with real-shaped values you can trace from step to step. This example is an Offers APIplacement running a two-goal offer ("signup", then "deposit") and the shipped default templates. The cast:

• Your user: u123 (the user_id you sent on the feed call).
• The offer: id 64f3b2a1c9d4e5f601234567, paying you $2.50 for signup and $7.50 for deposit; your placement margin leaves the user reward at $1.25 / $3.75.
• Your shared secret: kq8Zw3vN7Rp2 (what you swapped in for YOUR_SECRET when you saved the templates).

1. 1u123 opens the offer.You linked them to the feed's trackingUrl; we record the click and mint its id: b3f1c9a2-7e44-4f1a-9c2d-0a6e8d5b21c7. Everything that follows hangs off that one id.
2. 2The signup goal is approved → we GET your primary postback URL. With the default template, every param is present; note points= arriving empty (no coin step on this channel) and event=signup:
   Primary postback: goal 1 (signup)Copy

   https://your-site.com/postback?key=kq8Zw3vN7Rp2&user_id=u123&tx=b3f1c9a2-7e44-4f1a-9c2d-0a6e8d5b21c7&points=&payout=1.25&currency=USD&offer_id=64f3b2a1c9d4e5f601234567&status=approved&event=signup

   Your handler: status is approved, the pair (b3f1c9a2…, signup) is new → store it, convert payout=1.25 into your currency, credit u123, answer 200.
3. 3A week later u123 deposits → a second, separate credit on the same click. Same tx, different event:
   Primary postback: goal 2 (deposit)Copy

   https://your-site.com/postback?key=kq8Zw3vN7Rp2&user_id=u123&tx=b3f1c9a2-7e44-4f1a-9c2d-0a6e8d5b21c7&points=&payout=3.75&currency=USD&offer_id=64f3b2a1c9d4e5f601234567&status=approved&event=deposit

   The pair (b3f1c9a2…, deposit) is new → credit again. A handler deduping on txalone would have answered "already processed" here and silently kept u123's deposit reward. That is the bug the pair exists to prevent.
4. 4The signup conversion is charged back → a reversal arrives, on your reversal URL only, never on the URL above. With the default reversal template:
   Reversal postback (separate URL)Copy

   https://your-site.com/reversal?key=kq8Zw3vN7Rp2&user_id=u123&tx=b3f1c9a2-7e44-4f1a-9c2d-0a6e8d5b21c7&event=d9c1e6b0-2f7a-4c3e-8a11-6f2b8c4d7e90&coins=0&points=0&payout=2.00&reason=chargeback&status=reversed

   Read it carefully against step 2: tx is the same click id, so you can join it to the credits you stored, but event is now a fresh delivery UUID, not "signup", and coins=0 and points=0 because an Offers API conversion has no coin layer; payout=2.00 carries the full USD value credited at approval, which is the amount to take back. Your handler: status is reversed → take the reversal branch, check the UUID d9c1e6b0… is unseen (dedupe key on this channel), record it, take back what you credited for the signup, answer 200. If the delivery is retried, the same UUID arrives again and your check swallows it.

On a hosted wall the ids are identical; only the amounts change: points arrives filled (the amount in your currency), coins shows the coin grant, and currencyis your currency's name instead of USD. Same click id in tx, same goal id in event, and a reversal's tx joins to your stored credits the same way. See Dedupe keys per channel.

Prize Coin redemption

LootHQ runs a network-wide monthly leaderboard and awards winners Prize Coins. Users redeem those Prize Coins on your wall for your own currency, and you need to change nothing to support it.

Prize Coins have no cash value and cannot be withdrawn; redeeming them on a wall is the only way they can be spent. Full rules are in the contest terms.

Delivery and retries

A postback attempt succeeds when your endpoint returns an HTTP 2xx status within 10 seconds. Anything else (a non-2xx status, a timeout, or a connection error) is retried automatically on a fixed schedule:

Each value is the wait before the NEXT attempt, so that's 7 retries, or 8 attempts in total, with the last landing about 41 hours after the first. Then we give up and mark the delivery failed. Every retry (and a manual Resend) reuses the exact same {transaction_id} and {event_id} from the first attempt, which is why idempotent processing matters.

Every attempt (HTTP status, latency, a response snippet, and a timestamp) is logged and visible in Publisher Dashboard → Postback Deliveries. Deliveries that are still retrying or have failed outright can be re-fired on demand with the Resend button, without waiting for or restarting the schedule. A Resend never uses up one of those 8 attempts: it's counted separately on the delivery row, and a delivery that is still retrying keeps its full remaining budget and its existing next-retry time. Resend (and each remaining scheduled retry) re-reads your current saved postback URL first, so correcting a broken endpoint in Settings fixes the deliveries already in flight instead of replaying the old address. Only the endpoint changes: the {transaction_id} and every other value are carried over untouched, so your idempotency check still sees the same transaction.

If deliveries to one of your postback endpoints fail 3 or more times within 6 hours, we'll email you (at most once per 24h per endpoint) with which endpoint it was, its last result, and a link back to Postback Deliveries. An endpoint that silently rots stops crediting your users without either of us noticing, so this is how we make sure you find out.

Postbacks vs. webhooks

Two channels, two jobs. Postbacks credit users: a URL template with macros, the industry-standard rewarded channel. Webhooks are for reversals, reconciliation, and automation: signed JSON events, the Stripe/GitHub model.

Verify a webhook by recomputing the HMAC over timestamp + "." + rawBody with your signing secret and comparing in constant time:

const crypto = require("crypto");

// Mount with the RAW body so bytes match what we signed:
//   app.post("/webhooks", express.raw({ type: "application/json" }), handler)
function verifyLootHQWebhook(req, secret) {
  const sig = req.get("x-loothq-signature") || "";   // "sha256=<hex>"
  const ts  = req.get("x-loothq-timestamp") || "";
  const raw = req.body.toString("utf8");             // the raw bytes, not re-stringified JSON

  const expected = "sha256=" + crypto
    .createHmac("sha256", secret)
    .update(ts + "." + raw)
    .digest("hex");

  const a = Buffer.from(sig), b = Buffer.from(expected);
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) return false;

  // Reject stale deliveries (replay protection): 5-minute window.
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
  return true;
}

Securing your postback endpoint

LootHQ postbacks are fired from cloud infrastructure with dynamic egress IPs by default, so there is no standing IP list to whitelist. If your edge needs a fixed address before it will accept us, we can arrange one for your account on request. Either way, make a shared secret your actual check, not the address:

• 1. Put a secret token in your URL (recommended). You own the template URL, and LootHQ leaves any params it doesn't recognize untouched. The default template already carries the key= param. Replace YOUR_SECRETwith an unguessable token of your own (saving the literal placeholder gets you a warning, and your handler will reject every delivery until it's replaced) and reject any request that doesn't carry it. That alone stops strangers from crediting your users.
  Template with a hard-coded secret (save in Publisher Settings)Copy

  https://your-site.com/postback?key=YOUR_SECRET&user_id={user_id}&tx={transaction_id}&points={points}&payout={payout}

• 2. Idempotency. Only process each ({transaction_id}, {event_id}) pair once. Store the pair and return HTTP 200 for repeats without re-crediting. On prize redemptions {event_id} is empty and the pair degrades to the transaction id; on offers with more than one goal, only the pair is unique per credit. See Dedupe keys per channel.
• 3. Verify users. Confirm the user_id belongs to a valid account before crediting.
• 4. Postbacks are approvals only. {status} is always approvedon this channel; negative values and reversals are never sent here, by design. That doesn't mean reversals don't happen: if a conversion is later rejected by the advertiser (chargeback, fraud, void), we don't rewrite this postback; we claw the earning back on our side instead, per “When you earn” above. The reversed value is netted from your unpaid balance; the balance can dip negative and is recovered from future earnings, never billed. If you're subscribed on the Webhooks page you'll get a cryptographically signed conversion.reversed event (HMAC via the x-loothq-signature header) with the exact split, so you can optionally debit your own user too.
• 5. Logging. Log rejected postbacks with a reason so you can debug campaigns quickly.

Testing your setup

Use the built-in tools in the publisher dashboard to verify your integration before sending live traffic.

Run the Integration check first. One click runs every readiness check: URL saved, attribution macros present, a real delivery probe on each channel (it writes no delivery, conversion, stat or ledger row), and Offers API sub-id usage, each with a concrete fix. The steps below are the manual versions of the same checks.

1. 1. Configure your postback(s). Go to Settings → Publisher Settings and set your postback URL. If you want Tier 1 reversal notifications, set your reversal postback URL too.
2. 2. Open the Postback Tester. On the same Settings page, expand the Postback Tester section. It has three modes:
   • Test delivery (run this one first): a health check of the URL you just saved. It fires that URL through the exact outbound policy real deliveries use (HTTPS, the 10-second budget, and the 2-hop same-host redirect rule) and names the stage that failed: DNS, TLS, redirect, timeout, or the HTTP status itself. If it followed a redirect it prints the final address so you can save that instead. It writes no delivery, conversion, stat or ledger row on our side.It also sends the same {transaction_id} on every run (a fixed looptest-delivery-… value, alongside test=1), so running it twice is how you prove your duplicate check works: a correct handler processes the first and ignores the second. That id is not in the format we use for real conversions, so it can never collide with, or be mistaken for, a live transaction.That proves the retry case, where the id repeats and the credit must not. It cannot prove the multi-goal case, where the same {transaction_id} arrives with a different {event_id} for genuinely different credits. Passing this test does not mean your handler is safe for milestone offers. See Dedupe keys per channel.
   • Conversion: the original free-form tester. Build a URL against any endpoint (not necessarily your saved one) with custom values and fire it.
   • Reversal: fires your SAVED reversal postback URL through the real delivery pipeline, with a synthetic original {transaction_id} and a fresh {event_id}, clearly labeled as a test. A successful reversal test is how you prove your notification path before a real reversal needs it. Netting itself is not something you opt into: a reversal is netted from your unpaid balance always, on every account; this test is how you make sure you hear about it when it happens.
3. 3. Send a test. Choose a sample payout and subID, send a test, and confirm your endpoint returns HTTP 200.
4. 4. Verify credit. Check that your own app credits the test user with the expected reward.
5. 5. Test a webhook (optional). If you've subscribed an endpoint on the Webhooks page, the tester also has a Send test webhook button per endpoint: a real, signed conversion.reversed-shaped payload (marked test: true) so you can verify your signature-checking code against a genuine request.

Common errors

Here are some typical integration issues and how to fix them:

FAQ

Brand assets for your own site

Listing LootHQ alongside other offerwalls, or putting a header above your embedded wall? Use the card below rather than screenshotting a logo off our marketing pages. It is sized for an offerwall row and carries its own background, so it works on a light theme too.

Square tiles, app icons, transparent logos in WEBP and PNG, our hex colours and the usage rules are on the brand assets page. It needs no login, so you can send it straight to a designer.