Skip to main content
We ship fixes and improvements to the calculator continuously. The widget URL is stable — there is no version number in it — so salary.js always serves the current build. Whether your site picks up a new build automatically depends on how you embedded it.

​
Two integration modes

​
Script tag — updates are automatic

If your page loads the widget at runtime:
HTML
the browser fetches the current build every time the page loads. You get updates without doing anything. See Forcing an update if a cached copy is being served instead.

​
Bundled — you must redeploy

Some site builders and bundlers copy the widget into your own build output instead of fetching it at runtime. Framer does this, as do npm-based bundlers when you import the module. Your build then serves its own snapshot from your domain, usually under a content-hashed filename such as salary.a1b2c3.mjs. That snapshot never changes on its own. Rebuild and redeploy to pick up a new version — and remember to do it for every environment, including staging and demo sites.

​
Which mode am I in?

Open your browser’s developer tools, go to the Network tab, reload the page, and find the calculator script.

​
Which build am I running?

Check the last-modified response header on the calculator script in the same Network tab. It tells you when the build you are running was published. If it predates a fix you are expecting, you are on an older copy — either cached in your browser, or baked into your last deploy.

​
Forcing an update

1

Reload without the cache

A hard reload (Cmd/Ctrl + Shift + R) makes your browser re-fetch the script. Enough to confirm what the current build does, but it only affects the machine you are sitting at.
2

Add a version parameter for your visitors

A hard reload cannot clear your visitors’ caches. To push an update to everyone at once, change the URL by adding any parameter you control:
HTML
Browsers treat this as a new URL and fetch it fresh. Bump the value whenever you want to guarantee everyone is on the latest build. The widget reads its key from the query string, so extra parameters are safe to add.

​
Testing an update before it goes live

Point a staging page at the staging widget to try a build against your own integration first:
HTML
Staging keys and domain whitelists are separate from production — see Getting Started for both widget URLs.
If you bundle the widget, pin your staging and production deploys to the same build before comparing them. Otherwise you may be looking at two different versions without realising it.

​
What stays stable

Updates are meant to be drop-in. The embed snippet, the configuration options, the CSS variables, and the events are all part of the widget’s public surface, and we avoid breaking them.