Will this wrongly block my real customers?

That's exactly what we build against. A blocked customer rarely comes back, so the defaults lean cautious: we'd rather let a bot slip than wrongly stop a real person. You get a clear risk read and decide how strict to be — and you can dial it tighter or looser as you learn your own traffic.

Does it work for privacy-minded users — Brave, Tor, LibreWolf?

Yes, and they stay welcome. Privacy browsers don't break anything; we simply recognize them and treat them fairly instead of silently punishing the person behind them. If your product is built for sensitive audiences, you can choose to give those users extra leeway.

How accurate is it, really?

Accuracy depends on how strict you set things, and you control that. Rather than quote a single headline number, we show you how you're doing on your own traffic — broken down by browser and country — so you can see exactly where you're catching fraud and where you might be too aggressive. Better yet, run a trial and measure it yourself.

Do we need engineers to run this?

A little. A small script goes on your site and a single check happens on your server when you want a decision. There's nothing to host, nothing to keep running, and the heavy lifting is on us. Most teams are live in an afternoon — the step-by-step guide is in the docs.

Is it compliant — GDPR, CCPA, EU data?

Yes. We collect only the signals a check needs, store fingerprints as one-way hashes and no raw IP by default, and keep data in the EU. We'll sign a data-processing agreement, support hard-delete on request, and publish our subprocessor list. Your privacy and legal teams get straight answers, not hand-waving.

What if Noxtica has an outage?

Your site keeps working. If a check can't reach us in time, you get a safe default back so your code can fall back gracefully — challenge instead of block, for example — rather than locking anyone out. We commit to 99.95% uptime and publish a public status page.

Can we run it on our own infrastructure?

Yes — Enterprise customers can self-host, including air-gapped setups, with the same behavior as the hosted service and no outside dependency. Talk to us and we'll scope it with you.

Will it slow down my site or checkout?

No. The script loads quietly in the background without holding up your page. The check itself is a single, fast read before your page logic continues, so it fits inside a normal checkout or login flow without adding a separate step for the customer. Exact timing varies with traffic and device — the performance details are in the docs.

What does it actually send over the network?

Just one sealed, tamper-proof token — nothing else. No tracking beacons, no analytics pixels, no third-party calls in the path. You can inspect exactly what's sent; the full breakdown is in the docs.

How is this different from a CAPTCHA?

A CAPTCHA makes everyone prove they're human, which annoys real customers and rarely stops determined bots. Noxtica works invisibly in the background and only asks for friction when something genuinely looks off — so most of your customers never notice it's there.

Frequently Asked Questions

These answers focus on what an integrator can observe and control. For deployment eligibility, contractual terms, or a capability not shown in your account, use the contact page.

Does this work with Tor?

Tor and other anonymizing networks can be assessed, but the available evidence and confidence can differ from an ordinary browser path. Network context is one input; it should not become an automatic block by itself.

If your service is designed for people who rely on Tor, define that operating requirement before you evaluate a policy. Run in observation mode, compare outcomes on your own traffic, and choose a route-specific response. See Privacy-browser handling.

What about privacy-focused browsers — Brave, LibreWolf, Tor?

The collector is designed to continue when browser capabilities or storage are restricted. A hardened browser may yield reduced evidence, a different confidence level, a suppressed browser verdict, or no fresh assessment if scripts or network requests are blocked.

Keep those states distinct from low risk. Do not challenge or block solely because a visitor uses a privacy-focused browser. Evaluate the scored evidence and your business context, and maintain a usable fallback when collection cannot run.

How much does it add to my page?

The collector loads asynchronously, and the cache-respecting path avoids a full assessment on every eligible visit. The optional session-replay head helper is synchronous because it covers the earliest part of the page; omit it when replay is not part of your integration.

Measure the exact deployment on your pages. Compare before and after in your normal performance tooling, confirm fromCache on repeat visits, and inspect the Network panel for blocked or repeated requests. Asset size and assessment work can change across releases, so do not build a performance budget from a stale documentation number.

Do we need to run a backend?

You need a backend for trusted application decisions. The browser collector can return a fingerprintId and, when not suppressed, coarse score fields. Your backend uses a secret sk_... API key to retrieve the tenant-scoped device record and combines it with your own account, authentication, or transaction context.

Keep secret keys off the browser. A browser result is useful for UI state and diagnostics, but high-impact allow, step-up, or block decisions belong on your server. Follow Backend Integration.

Are you compliant with privacy regulation?

Compliance depends on your use case, jurisdiction, configuration, contract, disclosures, retention, and consent or other lawful basis. This integration guide cannot make that determination for you.

Before production use:

review the current Privacy Policy and Subprocessors;
confirm the data and deployment terms applicable to your account;
involve your privacy or legal owner in replay and behavioral-capture decisions;
connect optional capture to the consent or lawful-basis workflow your organization approves; and
verify denial, deletion, and retention behavior required by your own policy.

The base device assessment, session replay, and optional behavioral features are separate capabilities. Enabling one does not imply consent for another.

What’s your false-positive rate?

There is no responsible universal number for your traffic and policy. Your rate depends on the population, protected operation, threshold, confidence requirement, labels, and what you count as a false positive.

Measure on your own traffic before enforcement:

calculate the proposed action in observation mode;
join it with confirmed customer or abuse outcomes from your system;
segment by protected route and relevant customer cohorts;
review cases that would have created customer friction; and
promote only a threshold and fallback policy your team accepts.

Use authenticated event and export views available to your API scopes, the operator console, and eligible session replay for investigation. See Evaluate Before You Enforce.

What happens if your service is down?

Treat a script load failure, request timeout, network error, HTTP 5xx, or rejected SDK promise as unavailable. An unavailable result has no fresh score and must not be converted to 0, minimal, or low.

Choose the fallback per operation. A read-only page may continue, while a password reset or high-value transaction may require step-up verification or review. Keep your fallback independent of the Noxtica response path, set an application deadline, avoid tight retries, and record enough request context to investigate. Current service information is available at status.noxtica.com.

Suppressed is different from unavailable: a suppressed browser result indicates that assessment completed but browser-visible numeric verdict fields were withheld. Use its fingerprintId for an authenticated backend lookup.

Can I run this on-prem?

Deployment models and on-premises eligibility are account- and contract-specific. Do not plan an on-premises or disconnected rollout from a generic documentation statement; confirm the supported package, update path, operating responsibilities, data boundary, and capability set for your account through contact.

When evaluating that model, assign ownership for updates, monitoring, capacity, key management, retention, incident response, and calibration review. Also confirm which browser, server, operator, replay, and export functions are included. A self-managed deployment changes who operates the service; it does not remove the need for an unavailable-result policy.

How do you handle embedded widgets and frames?

Collection can run in an embedded frame when browser policy, sandbox permissions, origin registration, and network policy allow it. Some browser capabilities can be reduced in an embedded context.

Treat the frame context as context, not as an automatic risk decision. Test the real host and embed origins, register the correct origin, and verify postMessage or application handoff behavior you own. If collection is blocked or reduced, use the same unknown or unavailable policy as any other constrained browser path.

What does the collector send over the network?

The browser loads the public collector asset and contacts the configured collector origin for the policy and collection requests required by the integration. Your backend separately calls authenticated Server API endpoints. If eligible session replay is enabled and admitted by policy and consent, it creates additional replay traffic; it is not part of the base result alone.

Confirm the exact behavior in the browser Network panel for your configuration. Filter by collect.noxtica.com or your provisioned collector origin, exercise scored, suppressed, denied-consent, cache-hit, and error paths, and compare the observed requests with your privacy and security review. Do not assume an async-only, replay-enabled, and self-managed deployment have identical network behavior.

Can I customize the risk thresholds?

Your application owns the mapping from a scored risk record to allow, observe, step-up, or block. Operator controls available to your account may also support per-domain or per-surface policy.

Start in observation mode. Compare proposed actions with real outcomes, set confidence requirements, and define suppressed, missing, and unavailable handling separately. Change one policy boundary at a time and retain a rollback path. See Browser Security and Integration Flow.

What’s the difference between Noxtica and a CAPTCHA?

A CAPTCHA is an interaction that asks a visitor to complete a challenge. Noxtica provides a risk read your policy can use before deciding whether additional verification is appropriate.

They can be complementary: allow the normal journey when the scored evidence and your other controls support it, use a CAPTCHA or another step-up for elevated or unknown cases, and reserve denial for reviewed cases. Do not treat a CAPTCHA pass or a low Noxtica score as identity proof on its own.

Result States and Safe Handling

Model the integration as explicit states:

State	What you observed	Safe interpretation
Scored	Score, risk level, and confidence are present.	Apply the policy reviewed for that operation.
Suppressed	Assessment completed, but browser numeric fields are absent and a coarse status is present.	Risk is unknown in browser code; perform the authenticated backend lookup.
Cached	`fromCache` is true.	This is a freshness marker, not a risk tier.
Unknown	Backend lookup returns `404` or no current record.	Apply your new or missing-device policy.
Unavailable	Timeout, network failure, SDK rejection, `429`, or `5xx`.	Apply the operation’s availability fallback.
Error	Configuration or integration failure such as origin, key, scope, or CSP.	Fix the integration; never classify it as low risk.

Only a scored state belongs in a numeric threshold comparison.

Technical reference

The public contract is the supported SDK methods, browser events, result fields, and authenticated API responses. Internal detector names, runtime files, key identifiers, and weighting mechanisms are not integration contracts.

Tor handling and application policy

The current public SDK contract does not require a Tor-specific client option. Use the scored record, confidence, public reason information available to your server, and your route policy. If an older example names an undocumented Tor option, do not copy it into a new integration.

Network classification lists

Authenticated scoring can include infrastructure and anonymization context. Treat that context as one category of evidence. Availability or classification can change, and an unavailable source should reduce what you know rather than silently prove low risk.

Result integrity and key handling

The SDK manages browser result integrity under its supported verification mode. Keep the default required posture unless your security review approves a change. Do not pin an undocumented signing-key identifier or parse an internal token format.

For a trusted application decision, use fingerprintId with GET /v1/device/:deviceId from your backend. Keep the sk_... key in a server-side secret manager.

Bundle size

Measure the public asset or package version you deploy. The loader is asynchronous; additional work depends on the current policy, browser capability, and optional features. A pinned deployment must update its asset URL and published integrity value together.

False-positive evaluation basis

A useful evaluation set comes from your own labeled outcomes and preserves the route, policy version, risk state, score when present, confidence, proposed action, final action, and outcome. Include suppressed, unknown, and unavailable cases; excluding them makes the policy look safer than the customer experience is.

Service-degradation contract

The application contract should not depend on a fabricated neutral score. Use a discriminated state instead:

{ state: 'scored', score, riskLevel, confidence }
{ state: 'suppressed', fingerprintId, status }
{ state: 'unknown', reason: 'device_not_found' }
{ state: 'unavailable', reason: 'timeout_or_error' }

Only scored enters a numeric threshold. Define the other actions per protected operation and test them without Noxtica being reachable.

Headless and automation tells

Automation evidence contributes to the risk read. Detailed server and operator views are the appropriate place to investigate it; do not expose detector-specific reasons in browser messages or write policy against undocumented codes. See Detection Signals.

Iframes and reduced browser evidence

Embedded contexts can restrict storage, browser APIs, and network access. Register the actual origin, test the sandbox attributes used by the host, and treat reduced evidence as reduced confidence—not as automatic abuse and not as a clean result.

Network payload

During integration, use the Network panel to inventory the requests produced by your chosen path:

public script and policy requests;
collection submission or cache-hit behavior;
optional replay requests after admission; and
authenticated backend API calls, which should never appear in the browser.

Repeat the inventory with consent denied, storage unavailable, CSP restrictions, and your collector origin unreachable.

Getting Started — supported installation and consent qualifications.
Browser Runtime — collection lifecycle, replay states, and troubleshooting.
Backend Integration — authenticated lookup and server-side policy.
Integration Flow — the observe-first rollout.
Features Reference — customer operations and capability outputs.
Threat Categories — public risk categories and privacy-browser handling.