Getting Started
This guide will help you add Noxtica to your web application in just a few minutes.
Prerequisites
- A Noxtica account (request access via contact)
- Your Site Key (provided after account setup)
Quick Integration
Once your account is set up and you have your Site Key, add our collector to your HTML — that’s the whole install.
Automatic Collection (Recommended)
The simplest way to get started is to let Noxtica run itself, using run-once mode:
<script
src="https://collect.noxtica.com/collector/noxtica.js"
data-site-key="pk_prod_your_site_key_here"
data-auto-init
data-auto-check-once
async
></script>
This will:
- Assess a visitor on their first visit
- Reuse that result for repeat visits within the cache window (default: 7 days)
- Quietly record return visits without redoing the full assessment
- Coordinate across open tabs so a visitor is only assessed once
Results are available via:
// Listen for results
document.addEventListener('noxtica:collected', function (e) {
console.log('Fingerprint collected:', e.detail);
console.log('Risk score:', e.detail.score);
console.log('Risk level:', e.detail.risk_level);
});
// Or access directly after collection
console.log(window.noxticaResult);
Manual Collection
For more control, use the JavaScript API:
<script src="https://collect.noxtica.com/collector/noxtica.js"></script>
<script>
// Create a client with your Site Key
const client = NoxticaCollector.createClient({
siteKey: 'pk_prod_your_site_key_here',
});
// Collect and submit in one call
client.collectAndSubmit().then((result) => {
console.log('Risk score:', result.score);
console.log('Risk level:', result.risk_level);
console.log('Flags:', result.flags);
});
</script>
Smart Collection with checkOnce()
For the lightest footprint, use checkOnce() — it respects the collection interval you configure on the server, so visitors aren’t reassessed more often than they need to be:
const client = NoxticaCollector.createClient({
siteKey: 'pk_prod_your_site_key_here',
});
// Only collects if outside the check interval window (default: 7 days)
// Otherwise records a visit and returns cached result
const result = await client.checkOnce();
if (result.fromCache) {
console.log('Using cached result, next collection in:', result.nextSubmitIn, 'days');
} else {
console.log('Fresh collection submitted');
}
console.log('Risk level:', result.risk_level);
Performance & Site Impact
The collector is designed to have minimal impact on page load and user-visible latency:
| Metric | Value |
|---|---|
| Initial script size | ~167 KB minified, ~55 KB brotli |
| Time to collect (median, fp) | <50 ms on modern desktop / <120 ms on mid-tier phones |
| Time to risk-scored response | <150 ms median (collector edge → API edge) |
| Cached visit (post-first-load) | <10 ms (no fingerprinting work; just a beacon) |
| Main-thread blocking | None — collection runs in async chunks |
How we keep it light:
asyncscript attribute — the collector loads in the background and never delays your page from becoming visible or interactive.- Run-once mode (
data-auto-check-once) — after the first assessment, repeat visits within the cache window only send a tiny visit ping (~150 bytes). - Cross-tab coordination — multiple open tabs collapse to a single assessment.
- Cached after first load — the tamper-resistant KHAN VM is cached by the browser, so it loads instantly on later visits.
- Background processing where supported, so the work stays off the main thread and your page stays responsive.
If you notice a slowdown after adding the SDK, capture a profile with await client.collectAndSubmit({ telemetry: true }) — the returned result.telemetry includes a timing breakdown.
Sandbox vs Production
You’ll have two Site Keys: one for development and staging, one for production. Each runs under its own policies and keeps its data fully separate.
| Aspect | Sandbox (pk_sand_*) | Production (pk_prod_*) |
|---|---|---|
| Site Key prefix | pk_sand_ | pk_prod_ |
| Origin allowlist | Localhost + your staging origins | Strict — your registered origins only |
| Rate limit | Generous (~1000/min/IP) | Per-plan limits enforced |
| Risk scoring policy | Permissive — minimum bot blocking | Production policies applied |
| Data retention | 7 days | Per-tenant config (default 90 days) |
| Audit log retention | 7 days | Per-tenant config (default 90 days) |
| Step-up MFA | Optional | Required for destructive ops |
Always switch the Site Key per environment. Never use a pk_sand_* key in production traffic — sandbox data won’t appear in your production dashboards and risk scoring will be too lenient. Conversely, using a pk_prod_* key in development burns through production rate-limit budget.
A common pattern:
<script>
// Pick the key by hostname; fall back to sandbox in dev.
const KEY = location.hostname === 'www.example.com' ? 'pk_prod_REPLACE_ME' : 'pk_sand_REPLACE_ME';
const s = document.createElement('script');
s.src = 'https://collect.noxtica.com/collector/noxtica.js';
s.async = true;
s.dataset.siteKey = KEY;
s.dataset.autoInit = '';
s.dataset.autoCheckOnce = '';
document.head.appendChild(s);
</script>
Tag Manager Compatibility
The collector works inside Google Tag Manager, Adobe Launch, Tealium, and Segment, BUT with caveats:
Recommended (preferred): add the script directly to your HTML, immediately before </body> or in <head> with async. Starting as early as possible gives the collector the best head start, so it’s ready by the time a visitor interacts.
Tag managers — works, with caveats:
- ✅ Most modern tag managers (GTM Custom HTML, Adobe Launch Custom Code, Segment Custom Source) load the collector successfully.
- ⚠️ Consent gates that block scripts until a visitor accepts will delay the first assessment — usually nothing runs until the consent banner is dismissed. This is the right behavior; just know it can skew your “time-to-decision” metrics.
- ⚠️ Some older tag managers drop custom
data-*attributes. Ifdata-site-keydoesn’t reach the script tag, auto-init won’t start. Set it up yourself in code instead:NoxticaCollector.createClient({ siteKey: 'pk_prod_...' }).checkOnce(); - ❌ A few heavily sandboxed tag containers (rare) prevent the tamper-resistant runtime from starting. The SDK keeps working with a lighter form of collection and logs a console warning.
If you must integrate via tag manager, configure it to fire the Noxtica tag on All Pages — Window Loaded (or equivalent) rather than DOM Ready — this makes sure the consent state is final before anything runs.
Content Security Policy
If your site uses a content-security-policy, you’ll need to allow Noxtica to load, run its tamper-resistant runtime (the KHAN VM), and talk to our API. The example below covers all three:
Content-Security-Policy:
default-src 'self';
script-src 'self' 'wasm-unsafe-eval' https://collect.noxtica.com;
connect-src 'self' https://collect.noxtica.com;
If the policy leaves out the 'wasm-unsafe-eval' token, the browser blocks the tamper-resistant runtime and you’ll see a related warning in the console. Noxtica keeps working — it falls back to a lighter form of collection — but with weaker tamper protection. Adding the token above restores the full experience.
Site Keys
Your Site Key (pk_...) is a public identifier that authenticates requests from your domain. Each domain you add in the Backoffice gets a unique Site Key.
Important notes:
- Site Keys are public and can safely be embedded in your HTML
- Each Site Key is tied to a specific origin (e.g.,
https://example.com) - The API will reject requests where the origin doesn’t match the Site Key’s registered domain
Configuration Options
const client = NoxticaCollector.createClient({
// Your Site Key (required)
siteKey: 'pk_prod_your_site_key_here',
// API endpoint (defaults to production)
apiUrl: 'https://collect.noxtica.com',
// Collection mode: 'max' (default), 'standard', or 'minimal'
// Omit to use max mode (recommended)
// mode: 'standard', // Uncomment to opt out of max-only signals
});
Collection Modes
| Mode | Signals | Best For |
|---|---|---|
minimal | A small core set of signals | Fastest collection, lowest footprint |
standard | A broad set of signals | Sites that prefer a lighter-touch set of signals |
max | The full set of signals | Maximum accuracy (default) |
Response Format
After collecting and submitting, you receive:
{
"success": true,
"fingerprintId": "abc123...",
"score": 15,
"risk_level": "minimal",
"confidence": 0.5,
"flags": [],
"details": {
"summary": "Detected 0 risk indicator(s)."
}
}
Risk Levels
| Score | Level | Meaning |
|---|---|---|
| 0-19 | minimal | Very low risk, likely legitimate |
| 20-39 | low | Low risk, minor anomalies |
| 40-59 | medium | Moderate risk, some flags |
| 60-79 | high | High risk, likely automation |
| 80-100 | critical | Very high risk, confirmed bot |
Authentication
The SDK authenticates each visit with short-lived, automatically rotated credentials tied to your Site Key. It requests them, refreshes them, and attaches them to every submission for you.
You don’t need to manage any of this — the SDK handles it automatically.
Onboarding Process
- Request access: Contact us to request a demo or get started
- Account setup: We create your tenant account in the platform
- Add domains: Log into Backoffice, go to Domains, and add your origins
- Copy Site Key: Each domain gets a unique Site Key
- Integrate: Add the script with your Site Key to your pages
- Monitor: View fingerprints and analytics in the Backoffice dashboard
Managing Multiple Domains
Noxtica supports multiple domains per account:
- Production:
https://www.yoursite.com - Staging:
https://staging.yoursite.com - Mobile:
https://m.yoursite.com
Each domain has its own Site Key. You can:
- Enable/disable domains without regenerating keys
- Rotate Site Keys if compromised
- View analytics filtered by domain
SDK Version
Current SDK version: 3.3.0 (Schema: 2026-05-24)
What’s new in 3.3.0
- Lightweight behavioral signals (always-on) — simple timing cues like how long a session lasts and how quickly a visitor first interacts. No biometric data, and no end-user consent required.
- Behavioral biometrics (opt-in) — when you turn it on in Backoffice → Settings → Behavioral Biometrics, Noxtica also looks at the rhythm of mouse movement, click timing, and scrolling. This counts as biometric data under strict privacy regulation, so explicit end-user consent is required. See Behavioral Biometrics below.
- Apple Pay consistency check — confirms that a device claiming to be an iPhone actually behaves like one, catching a common spoofing trick.
- Network-fingerprint matching — recognizes the tell-tale connection patterns of common automation tools, so traffic from scripts and bots stands out even when the browser looks convincing.
- IP reputation — flags visitors arriving from networks with a poor reputation, with the option to plug in your own preferred threat-intelligence feed.
Behavioral Biometrics (Optional, Opt-In)
Noxtica can also study the rhythm of how someone moves the mouse, clicks, and scrolls. It’s an opt-in feature, turned off by default.
Why opt-in? This kind of behavioral data counts as sensitive personal data under strict privacy regulation, so capturing it requires explicit consent from your end user. We make it opt-in so you stay in control of when and how it’s used.
To enable:
- Log into Backoffice → Settings → Behavioral Biometrics
- Review the compliance notice with your privacy or legal team
- Update your privacy policy and consent banner to disclose this capture
- Toggle the feature on
Once enabled, Noxtica automatically factors these behavioral signals into future assessments, and your dashboard shows the resulting behavioral score per domain.
Next Steps
- Try the live demo to see fingerprinting in action
- Read the Backend Integration guide for server-side lookups
- Access the dashboard to explore collected data