How to Add an Offerwall to a Website or App

An offerwall integration has two jobs: show each user eligible offers and credit that user when a conversion is confirmed. ClixWall supports an embedded Wall for websites and apps, plus an Offers API if you need to build your own offer list. In either case, set up a server-side postback so rewards reach the right account.

This guide covers the implementation path. For platform-specific code samples and the current parameter reference, keep the ClixWall integration documentation open alongside it.

1. Create a publisher website

Create a publisher account and add your website or app under Websites in the publisher dashboard. Enter its name and URL. ClixWall reviews new websites, and each one has its own API key on its website page. You can also set an in-app currency name, revenue share, currency image, and primary color there.

Decide how your own system will identify the person opening the Wall. Use a stable, opaque user ID from your account system, and use that same ID when you process rewards. Do not use an email address or a device advertising ID as the Wall user ID.

2. Choose an offerwall integration method

For an iframe or WebView, the Wall URL has this form:

https://clixwall.com/wall?api=YOUR_API_KEY&user=URL_ENCODED_USER_ID

api is the key for your publisher website. user is the ID of the signed-in user who should receive the reward. URL-encode parameter values when building the URL. You may add theme=light or theme=dark; currency and branding settings are managed on your publisher website page.

Embed on a website

<iframe
  src="https://clixwall.com/wall?api=YOUR_API_KEY&user=URL_ENCODED_USER_ID"
  title="ClixWall offers"
  width="100%"
  height="600"
  allow="clipboard-write"
></iframe>

Generate the src for the current signed-in user. Place the entry point where users expect to earn rewards, and explain when their balance will update.

Load in a mobile app

Load the same URL in a WebView, with the current user's ID. The integration documentation includes examples for React Native, Expo, Flutter, Android, and iOS. Keep your reward balance in your own system; a user closing the WebView is not proof that an offer converted. Refresh the balance after they return to your app if you want to show newly confirmed rewards.

Build an offer list with the API

If you need a custom UI, use the Offers API reference. From your server, send your active publisher API key as a Bearer token to GET https://api.clixwall.com/v1/offers, with a user_id and optional country. When a user chooses an offer, call POST https://api.clixwall.com/v1/clicks with its offer_id and that user's user_id, then send the user to the returned redirect_url.

Keep the Bearer key on your server for this API flow. The click endpoint also accepts an optional sub_id; see the reference for its user ID rules, response fields, and duplicate-click behavior. API clicks still need a configured postback to credit your users after a confirmed conversion.

3. Configure your postback URL

A postback is a request from ClixWall to an endpoint you control when a conversion or reversal is processed. Add your publicly reachable postback URL in your publisher website settings. You can put supported placeholders in the URL so ClixWall substitutes the event values:

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

The important values are the user ID, the amount to credit that user, the unique transaction ID, and the status. publisher_payout is your payout for the conversion; it is separate from user_payout. The postback reference lists all supported placeholders and the legacy field names. For the callback flow and balance checks, see how postback URLs work.

For standard offer and task events, ClixWall sends a form-encoded POST to your configured URL. If the URL has no query parameters, the request body includes default fields such as u (user), c (user credit), payout (publisher payout), cid (offer or task ID), transaction_id, and s (status). If you use placeholders in the URL, read those values from its query string. Check the actual request with a test postback before relying on one format in production.

4. Credit users safely

Process postbacks on your server, in a database transaction where possible:

1. Check the endpoint secret and locate the user identified by the postback.
2. Read the transaction ID and status. Store a unique record for each processed event so a duplicate request does not credit the user twice.
3. Apply a confirmed credit or reversal to that user's balance, using the user payout amount rather than the publisher payout.
4. Record the event and outcome so you can investigate missing or disputed rewards.

Only treat a postback as processed after your database update succeeds. Return a successful HTTP response for events you processed or recognized as duplicates, and log failures. Do not rely on an automatic retry schedule: the integration should let you reconcile failed deliveries against the conversion history in your publisher dashboard.

5. Send a test postback and check the Wall

On the publisher website page, open Settings → Test to send a sample conversion to your configured postback URL. The dashboard displays the HTTP status code returned by your server. Use a test user ID, then check that your own balance and transaction record changed exactly once. A successful HTTP status alone does not prove your crediting logic worked.

Also open the Wall URL with a test user, confirm that the iframe or WebView renders, and check that its user ID matches the ID your postback handler expects. Test on each app platform you support. Before launch, verify that your endpoint is publicly reachable and that your handling of both credits and reversals works as expected.

After launch

Make the offerwall easy to find and explain the reward clearly. Watch actual opens, confirmed conversions, and reward support tickets before changing placement or copy. If users report missing rewards, compare their user ID and transaction history with your server logs and publisher dashboard records.

For the product and payout overview, see ClixWall for publishers.