How to Rotate Your Keys and Link Salt

How do I rotate my keys and link hash salt?

Go to Apps, click Manage, and open the Integration tab. Under 2. Keys and security, use Replace your keys and click New link hash salt, New postback secret key, or New API key, then confirm. The old one stops working right away, so put the new value on your server at once.

Once your publisher application is approved, every app you create is live right away and has its Integration tab. Each app has its own three keys, so rotating the keys of one app never affects your other apps.

Which key does what

These keys belong on your server only. Never put them in a browser or an app. Click Show to see a key and Copy to copy it. The Integration tab has a switch at the top, How will you show the offers?, with Offerwall, Offers API, and Mobile SDK. The link hash salt and Link security show under Offerwall, and the API key under Offers API and Mobile SDK. If you cannot find a key, switch the view.

When to rotate a key

HMAC keys are meant to change from time to time. RFC 2104, the standard that defines HMAC, calls periodic key refreshment a fundamental security practice. The OWASP Secrets Management Cheat Sheet adds that regular rotation means stolen credentials only work for a short time, and that an exposed secret should be revoked, replaced, and removed from wherever it leaked. Rotate:

• Right away if a key was pasted in a public repository, a support chat, a screenshot, a client-side bundle, or a log file.
• When someone with access leaves, such as a developer or an agency.
• After a security notification you did not expect, or any sign your account was accessed by someone else.
• On a schedule you choose, for example once or twice a year, in a quiet hour.

If you keep code on GitHub, GitHub’s secret scanning docs describe how it finds hardcoded keys in your history and why you should rotate a leaked credential immediately: deleting the commit is not enough, because the old value stays in the history. How to keep your app secret safe covers storing keys so they do not leak in the first place.

Step by step: replace a key

1. In the sidebar under Publish, click Apps, then Manage next to the app.
2. Open the Integration tab. A live app opens on this tab.
3. Scroll to 2. Keys and security and find the box Replace your keys: “Use this if a key may have leaked. The old one stops working right away.”
4. Click the button for the key you want to replace:
   • New link hash salt: “Offerwall links made with the current salt stop working until you update your site.”
   • New postback secret key: “Your postback checks fail until you update the key on your server.”
   • New API key: “Offers API and Reporting API calls with the current key fail until you update it on your server.”
5. Read the question in the window that opens, and confirm.
6. The page reloads with a message such as “New link hash salt created. Update it where your server builds offerwall links.” Click Show and Copy next to the new key, and put it on your server.

Every change also creates a security notification under the bell, such as Link hash salt changed, Postback secret key changed, or API key changed. If you did not make the change, secure your account at once with Secure your Moonetix account and What to do if your account is compromised.

A safe rollout order

Because the old key stops working the moment you confirm, the gap between the click and your deploy is the time users or postbacks can fail. Keep it short:

1. Prepare the deploy. Make the key a single environment variable or config value, so changing it is one edit, not a code search.
2. Rotate one key at a time. If something breaks, you know which key caused it.
3. Click, copy, deploy. Replace the key in the dashboard, paste the new value, and restart or reload your app so it reads the new value. Remember config caches, such as Laravel’s config:cache.
4. Test. Use Check a link for a new salt, Send a test postback for a new secret key, or one API call for a new API key.
5. Catch up. Resend postbacks that failed in the gap.

What to update on your server

• After a new link hash salt: update the code that builds offerwall links. Until then, users get the Link not valid page. Links built with the old salt, for example in emails you already sent, stop working too. Use Check a link in Integration status, at the top of the same tab, to check your new links. If the link still fails, the checker lists an old salt among the most common causes: your server is still on the previous value.
• After a new postback secret key: update the key in your postback handler. Until then, the hash check on your server fails. Postbacks that failed in the meantime can be sent again with Resend in Reports > Postbacks, and a resent postback is signed with the new key. See How to resend a failed postback.
• After a new API key: update it everywhere your server calls the Offers API, the Reporting API, or creates SDK sessions. A dashboard script or a spreadsheet that pulls reports needs the new key as well; Reporting API quick start shows where it goes.

The Link security setting

Above the link hash salt, Link security controls the hash check:

• On (recommended): every offerwall link must carry a valid {HASH}, so nobody can open the offerwall of another user by changing the user ID. The button reads Turn off the hash check.
• Off: a Hash check is off badge appears, and links work without a {HASH}. Anyone who knows or guesses a user ID can open that user’s offerwall, including My offers. The link hash salt is marked Not in use, and New link hash salt is grayed out. Click Require the hash to turn the check back on.

Turning the check off asks you to confirm first. While it is off, the link and code shown in the Integration tab have no hash. Turn the check on before you go live. When you turn it on, every link needs a valid hash again, so make sure your server adds it first. More on why it matters: Postback security.

On a phone

Tap Apps in the bottom tab bar, then Manage. The app opens on Integration. If you are on another tab, swipe the row of tabs sideways to find it.

Two free tools help while you test: the offerwall link builder shows the link your server should build, and the postback hash checker verifies the postbacks you receive.

Frequently asked questions