Canonical Url

The one address for asset.js is https://statelessid.com/asset.js. This URL is stable, always HTTPS, and always the current build. No other path, version string, or CDN address is supported.

Why one URL for the current version

A single stable URL is a single surface to monitor, update, and trust. When the script is updated — to adjust class boundaries, change how the beacon is sent, or fix a behavior — the file at the canonical URL changes. Every site that loads from that URL picks up the update on the next page load with no action required.

Versioned filenames like asset.v2.js or asset.min.js signal that the client is responsible for version pinning and migration. StatelessID manages versioning on the server side. You load the path; you get current. There is no migration step when the script changes.

No CDN path, no alternate filename

asset.js is not distributed at a CDN path, a subdomain URL, or a named-version filename. The one path is /asset.js at statelessid.com. If a third-party integration or tutorial shows a different path, it is outdated or incorrect. Check the Script tab in your dashboard settings for the authoritative tag.

There is also no minified-only or debug variant. The hosted file is the file. What you load is what runs.

Self-hosting is not supported

Copying asset.js to your own server and serving it from your domain removes the connection to the live version. If the beacon format changes, the self-hosted copy continues sending the old format, which the server may reject or miscount. If class boundaries change, the old copy classifies visits differently. Neither problem is visible to you until counts diverge.

Self-hosting also complicates Content Security Policy configuration. The CSP rules that allow the script to load and send beacons are written for statelessid.com. A self-hosted copy needs different CSP rules, which vary by host. Loading from the canonical URL means the CSP instructions in the help articles apply without adjustment.

Subresource Integrity

Subresource Integrity (SRI) lets you add an integrity attribute to a script tag with a hash of the file's content. The browser refuses to execute the file if the hash does not match. SRI is designed for files that do not change — a pinned version of a library, for example.

Because asset.js updates at the same URL without a version change, an SRI hash pinned to today's build will break when the file is next updated. Do not add an integrity attribute to the asset.js script tag. The trust mechanism is HTTPS transport to the canonical hostname, not a content hash.

Troubleshooting

If you see a 404 on the script URL, check for a typo in the src attribute. The correct path is https://statelessid.com/asset.js — no subdirectory, no version string, no trailing slash after .js. Copy the snippet from your dashboard Settings → Script tab rather than typing the URL by hand.

If a security scanner reports that the asset.js script tag lacks an SRI hash and recommends adding one, the recommendation does not apply to a file that updates on a stable URL by design. The HTTPS connection to statelessid.com is the integrity mechanism. If your policy requires a response to this finding, document the update-on-stable-URL pattern as the exception.