How to Resend a Failed Postback

How do I resend a failed postback?

In the sidebar under Reports, click Postbacks, set Result to Not delivered, fix what made your server fail, and click Resend at the end of the row. A message confirms that the postback was sent again, and the new attempt appears at the top of the list a few seconds later. A 2xx answer in that new row means your server got the reward.

Postbacks start once a live app has a postback URL in its Postback tab. If you are new to them, What is a postback URL? explains the basics.

How automatic retries work before you need Resend

Moonetix counts a postback as delivered when your server answers with any 2xx status code within 6 seconds. It does not read the response body and does not follow redirects. When a call fails or times out, Moonetix tries again by itself up to 5 times:

Each try is its own row in the report, and Export CSV adds an Attempt column with the number of each try. If the last retry fails too, Moonetix emails you, at most once a day per app, with the subject “A postback to your server failed”. Resend is for those events, or for any event you want to send again now that your server is fixed. The full rules are on the Postbacks page of the docs.

Step by step: find and resend a failed postback

1. In the sidebar under Reports, click Postbacks. You can also click the postback report link in the Postback tab of your app, which opens the failed ones directly. When an app’s postback status shows Failing on its page, View failed postbacks takes you there too.
2. Set Result to Not delivered, or click the Not delivered total at the top. Use App and the date menu at the top right to narrow the list.
3. Look at the Event column (Credited or Reversed) and the Result column, which shows the HTTP code your server sent, such as HTTP 403, or No answer.
4. Click the URL under Details to see the full URL we called and the Response from your server.
5. Fix the cause on your side. If the postback URL was wrong, correct it in the Postback tab and click Save changes.
6. Back in the report, click Resend at the end of the row. A message confirms: “Postback sent again. The result appears at the top of this list in a few seconds.”
7. Check the new row at the top. A 2xx code means your server got it, and the old failed row now says Delivered later.

That rule makes your handler idempotent. MDN’s glossary defines idempotent as a request whose intended effect is the same whether it is made once or several times, which is exactly what you want when retries and resends can deliver one event more than once.

What the Postbacks report shows

When the Resend button shows

• Only for failed rows of real conversions. Test postbacks, marked Test in the Event column, cannot be resent. Use Send a test postback in Integration status on the Integration tab instead.
• Not if the event got through later. If a retry or an earlier resend was delivered, the row says Delivered later instead. If it was delivered in the meantime, you see “This event was already delivered to your server.”
• Not for an outdated event. If the result changed since then, for example a credited event whose result was later reversed, you see “This result has changed since then, so this older event is not sent again.”
• Not if the event is no longer sent. If the postback URL is now empty, you see “This event is not sent to your server any more. Check the postback URL of the app.” Add the URL again in the Postback tab first.

Resend uses the postback URL and postback secret key saved for the app now. If you changed your secret key since the first try, your server must check the hash with the new key. See How to rotate your keys and link salt.

Common causes of failed postbacks

The code in the Result column points to the cause. MDN’s list of HTTP status codes groups them into five classes: only 2xx counts as delivered, 3xx is a redirect, 4xx means your server refused the request, and 5xx means it failed while handling it.

Redirects catch people out most often, because a browser follows them silently. MDN’s guide to HTTP redirections explains that a redirect is a 3xx code plus a Location header; Moonetix stops at the 3xx and records it as not delivered.

If your server only accepts known addresses, add the IPv4 and IPv6 addresses from the Postbacks docs, as shown in Postback IP allowlist. Bot protection and firewalls that block server requests are a frequent cause of No answer. Always keep the hash check as well; Postback security shows a handler that does both.

After the fix: confirm before you resend

1. Use Send a test postback in Integration status on the Integration tab. It shows exactly what your server answered. Test transaction IDs start with test_, so your handler can tell them apart.
2. Once the test gets a 2xx, resend the real failed events one by one. Resend works one row at a time, with a short pause between clicks.
3. Check the user’s balance on your side. If a user already wrote in about the missing reward, Handling missing reward tickets has reply templates.

A full launch checklist is in How to test your app before launch, and every error with its fix is on the Testing and troubleshooting page.

On a phone

Tap Reports in the bottom tab bar, then the Postbacks tab at the top of the report. Tap Filters to set Result. Or open your app from Apps, go to the Postback tab, and tap the postback report link. Each row shows as a card, with Resend at the bottom.

To check your handler, paste a postback it received into the postback hash checker: it shows the exact string that is signed and why a hash does not match.

Frequently asked questions