Before:

After:

Find the new documentation at https://docs.innerworks.me.

By aggregating stats earlier, the dashboard now loads 2-3x faster, and will not be significantly impacted by more data.

The page as a whole is gated by its slowest query, which is why the headline is 2-3x rather than the 6.5x that VPN detection stats managed on its own.

There is now a Sign in with Microsoft button on the login screen, sitting alongside the existing Google option. Both work the same way, and you can mix and match across your team.

There is now a single endpoint that runs the whole pipeline. The shared analysis happens once and every detection type builds on it, so asking for several of them together is considerably faster than asking for them one at a time.

Historical data, the hard fingerprint and the VPN lookup are the three stages everything else is built on. Each is computed once per request, no matter how many results you ask for.

With one pipeline rather than a set of parallel ones, we can also add new detection types and iterate on the algorithms behind the existing ones much faster - and those improvements or access to beta versions reach you with minimal change.

The npm package is now a thin client. When it initialises, it fetches its detection core from our CDN at runtime. The upshot is that new signals and detection improvements reach your users automatically, without you needing to bump a dependency and redeploy.

The version you pin in package.json is the thin client. The detection core it pulls in is whatever we have published, so improvements land without a release on your side.

A couple of other changes worth knowing about while you are upgrading:

• send() is deprecated in favour of sendMetrics(). The old name still works and just forwards on.
• detectionResult on the response has been replaced by detectionResultJwt.
• detectionTypes is no longer a config option. Which detections run is now driven by your project configuration, so you can change it without a code change.

Until now, the only way to see what Innerworks was detecting was to query the API yourself. There is now a dashboard.

At the top are the numbers you probably care about most: total requests, active accounts, VPN detections and high-risk countries. Below that is a threat map that highlights where your traffic is coming from and flags VPN-originating sessions, and you can click a country on the map to filter everything else on the page down to it.

There is also an account clusters section, which surfaces groups of accounts that look linked by shared device or location activity.

You can narrow the whole dashboard by project, country, fingerprint and a date and time range, and your selections stay put as you move between sections. Every metric card carries a tooltip explaining exactly what it is counting.

It returns what your integration would return: the device fingerprint, VPN status and true geolocation, the detected OS and browser, the IP addresses we saw, and the decoded token. No project setup, no code.

It is the quickest way to see what a detection result actually looks like before you wire anything up, and a useful sanity check afterwards when you want to confirm a signal is behaving the way you expect.

As of v1.7.2 you get a structured response instead: an overall result, a request ID, the detection result itself, and per-detection-type errors when something partially fails.

The request ID is the useful part. Quote it to us in a support conversation and we can find the exact request. Pass it to the results endpoint and you can fetch the same detection result server-side, which is the recommended way to make a decision on it - a result read in the browser is a result an attacker can tamper with.

Partial results matter too. If you have asked for several detection types and one of them fails, you now get the ones that succeeded plus an error for the one that did not, rather than losing the whole response.

Every project has an API key, which you can reveal and copy from the portal. Take the request ID the SDK hands back and ask for the result directly:

curl --request GET \
  --url 'https://api.prod.innerworks.me/api/v1/innerworks/inference?request_id={REQUEST_ID}' \
  --header 'x-api-key: {API_KEY}'

The default response is the short version - the fingerprint, whether a VPN was in use, and the true location behind it. Pass format=detailed and you also get browser, OS, user ID, geolocation and the reasoning behind the detection.

This is the recommended way to act on a result. API access covers both response formats in full.

Results now come back as a signed JWT, and there is a JWKS endpoint you can verify it against:

https://api.prod.innerworks.me/api/v1/.well-known/jwks.json

Verify on your backend, not in the page - a check that runs in the browser can be skipped by anyone who controls the browser.

JWT verification has a worked example.

There is now a hosted version of the SDK you can embed directly:

<iframe
  id="innerworks_sdk"
  src="https://sdk.prod.innerworks.me?projectId=project_id"
  style="display: none;"
></iframe>

Configuration goes in the query string and results come back by postMessage, so you can read them from the parent page. Everything the npm package collects, the hosted page collects too.

iFrame integration has the full setup, including how to pass a social ID and how to handle the response.

The signals we collect describe a device, not a person, but they still travel across a network you do not control, so they should not travel in the clear. This happens inside the SDK - there is nothing to configure and nothing to change in your integration.

This prevents anyone from seeing what data is collected on the browser and sent to innerworks.