How to Test Your App Before It Goes Live

How do I test my Sharklio app before it goes live?

Open Apps, click Manage, and go to the Postback tab. Save your postback URL and click Send test under Send a test postback. Then use Test a link or Open your offerwall in the Integration tab to check the wall itself.

Publisher applications open soon. Your app can be tested once our team approves it. Approval makes the link work, but no user sees the wall until you add it to your site or app, so test first.

Step by step: test your postback

1. Go to Apps, click Manage next to your app, and open the Postback tab.
2. Paste your Postback URL with the macros you need, for example {user_id}, {transaction_id}, {status}, {reward}, and {hash}. Tick Also send pending events (status 3) if you want them. Click Save changes.
3. Scroll to Send a test postback. Fill in User ID (a test account on your site), choose a Status (Credited (1), Reversed (2), Pending (3), or Rejected (4)), and set Payout (USD).
4. Click Send test. We call your saved URL right away, and a Test postback result window opens.
5. Read the result. The top line says Your server accepted the test postback (any 2xx answer) or Your server did not accept the test postback. Below it you see the Response code, Answer time, The request we sent, and The exact answer from your server. Open The values we filled into your macros to see every value, including the reward in your currency.
6. Check your own system. A credited test should add the reward to that user once. Then undo any test reward.
7. Repeat for each status, waiting about 10 seconds between tests. Each test is a new transaction, so a reversed (2) test is for a transaction you never credited, and your server must accept it without taking anything away.
8. To check that a repeat never pays twice, open the test row in Reports > Postbacks, copy the URL under Details, and open it again. It is the same transaction with a valid hash, so nothing should change. Change one character of the hash and open it once more: your server must refuse it.

Every test transaction ID starts with test_ and the offer ID is 0, so your handler can verify the hash and then skip crediting if you prefer. The PHP and Laravel guide shows a handler that does exactly that. Click Copy full report to keep the result or send it to your developer.

Step by step: test the offerwall link

1. Open the Integration tab of the same app.
2. Under 1. Add the offerwall, open Test a link (shown while the hash check is on). Type a User ID, and the exact link your server should build appears. Click Copy or Open.
3. Build the link with your own code for the same user ID. The two links must be identical.
4. Open your link. You should see the offerwall, not the Link not valid page.
5. To click through the wall like a user, use Open your offerwall. It is in the Design tab, and for a Direct link app also in the Integration tab. It opens your real wall with the test user ID owner-test, whose clicks and results are left out of your statistics.

What the Postbacks report shows

Every test is also listed in Reports > Postbacks, with a Test badge in the Event column, your server’s HTTP code in Result, and the URL and response under Details. Tests count in the Calls, Delivered, and Failed totals, but they have no Resend button. Send a new test instead. Real events that fail can be resent, as How to resend a failed postback explains. Read How to read your dashboard and reports for the rest of the report.

Checklist before you go live

1. A credited test is accepted, and the user gets the reward once.
2. Opening the same postback URL a second time does not credit twice.
3. A reversed test for a transaction you never credited takes nothing away.
4. A postback with a wrong hash is refused by your server.
5. Your server answers within 6 seconds, without a redirect.
6. Your link matches the one from Test a link, and the wall opens on the right page.
7. The user ID never changes for the same person.

If something goes wrong

• Send test is grayed out. Save a postback URL first.
• HTTP 403 or 404. Your script rejected the call, or the URL is wrong. Check your hash code.
• HTTP 301 or 302. Your URL redirects. Use the final URL, because we do not follow redirects.
• No answer. A timeout, or a firewall or bot protection blocks our requests.

The full list of causes is on the Testing and troubleshooting page of our docs. For the hash itself, see Postback security.

Frequently asked questions