On this page

Getting Started

This guide is the starting point for a Noxtica technical evaluation. The developer overview links each step to the page that holds it.

Key points

  1. Request an evaluation firstThe team provisions the exact browser origin, public Site Key, and server access for the evaluated path.
  2. Use the verified loaderThe current publicly verified browser release is the loader served from the Noxtica collector origin. This guide gives no installation commands for anything else.
  3. Pass the device identifier, nothing moreA device identifier is a lookup handoff, not an identity credential. Keep server credentials out of browser code.
  4. Unavailable is not low riskEvery non-success state stays distinct from low risk. Successful installation alone does not establish a production-ready policy.
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

Before you integrate

Request a technical evaluation so the team can provision the exact browser origin, public Site Key, and server access needed for the evaluated path. Do not copy credentials or package names from private repositories, old examples, or another environment.

The current publicly verified browser release is the loader served from the Noxtica collector origin. No public npm package, framework wrapper, native SDK, server SDK, or Postman collection passed the 2026-09-20 release check, so this guide does not provide installation commands for them. They exist as private deliveries that your account team arranges: see SDK family and availability. The public API operations are published as an OpenAPI description at openapi.json, and Integrate with an AI agent shows how to hand these docs to an AI coding agent.

Copy your domain’s snippet from Backoffice → Integrations & API → Script & Consent and follow the install walkthrough, the single source for the scripts, CSP, consent modes, and checks.

Shortest maintained path

  1. Use the browser sample from the checked fixture.
  2. Observe both the collection-complete and collection-error paths.
  3. Send only the returned device identifier to your own backend.
  4. Use the server sample for the authenticated device lookup.
  5. Exercise received, missing, invalid, rate-limited, and unavailable states with the result-state sample.
  6. Compare proposed policy actions with outcomes in observation mode before enforcement.
  • Your page

    Browser sample

  • Your server

    Authenticated lookup

  • Your policy

    Observation mode

  1. Browser sample

    Use the browser sample rendered from the checked fixture.

  2. Both paths

    Observe both the collection-complete and the collection-error paths.

  3. Identifier

    Send just the returned device identifier to your own backend.

  4. Lookup

    Use the server sample for the authenticated device lookup.

  5. Every state

    Exercise received, missing, invalid, rate-limited, and unavailable states.

  6. Observe first

    Compare proposed policy actions with outcomes in observation mode before enforcement.

The shortest maintained path, step by step, and where each step runs

Application responsibility

The browser collector does not make your final signup, login, checkout, recovery, or access decision. Browser capability, tenant policy, privacy signals, and consent state can reduce or prevent collection. Your application must remain usable and apply its chosen fallback when no fresh evidence is available.

Keep server credentials out of browser code, URLs, client logs, and analytics. A device identifier is a lookup handoff, not an identity credential.

Browser collector

The browser collector does not make your final signup, login, checkout, recovery, or access decision.

Can reduce or prevent collection

  • Browser capability
  • Tenant policy
  • Privacy signals
  • Consent state

Your application

Your application must remain usable and apply its chosen fallback when there is no fresh evidence.

Keep server credentials out of

  • Browser code
  • URLs
  • Client logs
  • Analytics

Remember

  • A device identifier is a lookup handoff, not an identity credential.
Who is responsible for what: the browser collector and your application

Verify the evaluation

Confirm the exact origin is provisioned, collection can complete, the unavailable path remains usable, the backend can perform an authenticated read, and every non-success state stays distinct from low risk. Successful installation alone does not establish a production-ready policy.

Continue with Install & Browser Runtime, Backend Integration, and Integration Flow.