Browser Runtime

Use the developer overview for the verified release, current support matrix, and maintained browser fixture. This page describes the browser responsibility without advertising unverified packages or framework support.

Current public surface

The public collector loader reported version 3.2.0 when checked on 2026-09-20. It is served from the Noxtica collector origin. No public npm package, framework wrapper, native SDK, or cross-platform wrapper passed the same release check, so those surfaces are omitted rather than inferred from private inventory.

Use the maintained browser sample. It is read directly from the fixture checked by the developer snippet test.

Install: core on every page, extensions after consent

The collector is two scripts. The core (noxtica-collector-core.js) carries what runs without consent: the browser token, the minimal security check, server-requested challenges, the consent API, and protected actions. Load it on every page. The extensions (noxtica-collector-extensions.js) carry device recognition, analytics, replay, and behavioral capture. Load them only after the visitor consents, or right away if your domain’s consent mode is not_required. Each extension module still runs only when its category is granted.

<script
	src="https://collect.noxtica.com/collector/noxtica-collector-core.js"
	data-site-key="pk_prod_your_site_key_here"
	data-auto-init
	data-auto-check-once
	async
></script>

Load the extensions in one of three ways:

• add data-extensions="auto" to the core tag: the core loads them immediately in not_required mode and on the first granted category in the api and cookie modes;
• call await window.noxticaClient.loadExtensions() after your page grants consent (see Consent API);
• inject <script src="https://collect.noxtica.com/collector/noxtica-collector-extensions.js" async></script> yourself after consent. It carries no Site Key and attaches to the core already on the page.

Loading the extensions never grants consent by itself.

Protected actions. For steps attackers target, such as login, sign-up, checkout, or identity verification, declare them per domain in Backoffice and trigger them from the page: data-nox-protect="login" on the form, or const { requestId } = await window.noxticaClient.protect('login') before the request your server verifies. The core then runs a minimal check even without consent: nothing is stored on the device and no behavioral, replay, or analytics data is collected. Ordinary page views are never exempt.

Stable or pinned. The tags above always load the current build and never need updating. Use a pinned tag only if your security policy requires Subresource Integrity: take the hashed file and integrity value for each script from Backoffice → Integrations & API → Script & Consent or from https://collect.noxtica.com/collector/asset-manifest.json (keys noxtica-collector-core.js and noxtica-collector-extensions.js), and add crossorigin="anonymous". A pinned core loads the extensions with their own integrity hash. Each collector release replaces the hashed files and removes the previous ones, so copy the pinned tag again after every release, or fall back to the stable name (without integrity) when the pinned file fails to load. noxtica.com loads its own core this way.

Legacy — supported, migrate. The combined script https://collect.noxtica.com/collector/noxtica.js (also /collector/noxtica-collector.js) bundles core and extensions in one file. It keeps working unchanged, but it cannot separate consent-free from consent-gated collection. To migrate, replace it with the core tag (same data-* attributes) and add data-extensions="auto".

Backoffice shows these snippets with your domain’s Site Key under Integrations & API → Script & Consent, API Config → Client integration, and each domain’s Integration tab.

Browser responsibility

The browser loads the collector for the provisioned origin and public Site Key. It reports a collection result or an error state. If a result contains a device identifier, application code may pass that identifier to the customer backend for an authenticated lookup.

A server credential never belongs in browser JavaScript, HTML, a mobile application resource, a URL, or a client-visible log.

Capability and consent boundary

Evidence availability depends on the current browser, tenant configuration, privacy signals, and consent state. JavaScript disabled or blocked means no new browser assessment. Reduced evidence, a suppressed browser-visible result, and a transport error are different states; none is automatically low risk.

Optional behavioral or replay capture requires its separately reviewed eligibility and consent or lawful-basis path. The public loader alone does not authorize collection beyond the configuration approved for the evaluation.

Consent modes (tenant integration guide)

Consent modes let a domain split the collector into a consent-free core and consent-gated categories. The default, not_required, keeps today’s behavior unchanged; you do not need to change anything unless you choose a gated mode.

Choosing a mode

Set the mode per domain in Backoffice → Integrations & API → Script & Consent (/integrations/script-consent), stored as the domain’s client_consent_mode. The collector reads it when it issues the browser token.

Cookie names may use letters, digits, _, ., and -; values may additionally use :, %, and +. Backoffice rejects anything else. A value that cannot be parsed is treated as not_required, so the domain keeps its current behavior.

Declaring the mode on the loader (optional)

The Domain setting arrives with the first token. To apply gating from the moment the script runs, before that token returns, declare the same mode on the loader:

<script
	src="https://collect.noxtica.com/collector/noxtica-collector-core.js"
	data-site-key="pk_prod_your_site_key_here"
	data-consent-mode="api"
	data-auto-init
	data-auto-check-once
	async
></script>

Accepted forms are data-consent-mode="api", data-consent-mode="cookie:name" or data-consent-mode="cookie:name=value", and the shorthand data-consent-cookie="name" or data-consent-cookie="name=value". Programmatic clients pass the same value:

const client = NoxticaCollector.createClient({ siteKey: 'pk_prod_your_site_key_here', consentMode: 'api' });

A loader declaration can make the page stricter before the token arrives. The Domain setting stays authoritative for server enforcement.

Core and extensions in a gated mode

In the api and cookie modes, keep the core on every page and load the extensions only after the visitor accepts (see Install). With the api mode, grant the categories and then load the extensions:

const client = window.noxticaClient;
client.setConsent({ deviceId: 'granted', analytics: 'granted', replay: 'granted', behavioral: 'granted' });
await client.loadExtensions(); // true once the extensions are active

Each value is the string 'granted' or 'denied'; any other value, including true or false, throws an error. Adding data-extensions="auto" to the core tag makes the core load the extensions on the first granted category instead.

Consent API

With data-auto-init, the client is available as window.noxticaClient. Programmatic clients use the object returned by createClient.

• client.setConsent({ analytics, replay, deviceId, behavioral }) sets each listed category to 'granted' or 'denied'. Omitted keys keep their current state.
• client.setConsent('granted' | 'denied') is the legacy form. It changes analytics only.
• client.setReplayConsent(true | false) changes replay only.
• client.getConsent() returns the current state: { mode, analytics, replay, deviceId, behavioral }.

Example wiring with a generic CMP callback (OneTrust- or Cookiebot-style). Map your CMP’s purposes to Noxtica categories as your privacy team decides:

const client = window.noxticaClient;
const state = (allowed) => (allowed ? 'granted' : 'denied');

cmp.onConsentChanged((choices) => {
	client.setConsent({
		analytics: state(choices.statistics),
		replay: state(choices.statistics),
		deviceId: state(choices.preferences),
		behavioral: state(choices.marketing),
	});
});

In cookie modes the collector reads the cookie when it starts and again on visibilitychange and focus, so a decision made in your banner applies when the visitor returns to the tab. A grant applies to all categories at once. A missing or non-matching cookie denies all categories and purges the persistent device stores.

What runs without consent (core)

These parts run in every mode because they protect the page and its visitors:

• browser token issuance;
• /client/submit with the minimal sealed-runtime fingerprint;
• anti-automation counters (event counts and timing, no coordinates or key values);
• challenges that the server requests.

Until deviceId is granted, the device identifier stays in memory and sessionStorage and is not written to localStorage, IndexedDB, or cookies.

A category that is granted still depends on the tenant and domain features you have enabled; consent never switches on a feature your configuration leaves off.

Server enforcement

When a domain’s mode is anything other than not_required, the collector enforces consent on its side too. The loader adds an nxc query parameter naming the granted categories to each collector request; do not strip it in proxies or rewrite rules. The collector then:

• accepts and discards analytics payloads without analytics consent;
• accepts and discards replay payloads without replay consent;
• removes behavioral fields from /client/submit without behavioral consent;
• skips the persistent device-recognition token without deviceId consent.

A request without the parameter, for example from an older cached loader, counts as nothing granted. Discarded payloads still receive a normal success response, so the page never sees an error. Domains on not_required are not affected.

Persistent device recognition switched off

If persistent_device_recognition_enabled is false for the domain, the collector never persists the device identifier in gated modes, even after deviceId is granted.

Legal classification (not legal advice)

This table is informational and not legal advice; consult your DPO/counsel. Classification depends on your jurisdiction, purposes, and configuration.

Live assist is loaded separately and asks for its own consent; it is outside these categories.

Reliability checks

• Register both completion and error handling before relying on a result.
• Keep collection outside the page-rendering critical path.
• Preserve the normal customer journey when collection cannot run.
• Send only the returned device identifier to your backend.
• Do not put identifiers, raw results, or credentials in URLs or optional analytics.
• Test the browser versions and privacy modes your own application supports.

Next step

Follow Backend Integration for authenticated lookup states and Integration Flow for customer-owned policy rollout.