Testing

Testing your setup

The dashboard can exercise the whole path before you send any 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.