How Sentriq actually integrates

@sentriq/browser is the primary client-side integration path: initialize it with a public key, then call track() with a named event (login, signup, payment, and more). It collects only coarse, non-invasive signals — screen, hardware, platform, timezone, locale — never keystrokes, canvas, or audio fingerprints.

It returns a risk level and decision your own code acts on — Sentriq never hangs indefinitely on a critical path, and it never silently swallows a failure. @sentriq/react and @sentriq/next/client wrap this SDK for React/Next.js apps rather than reimplementing it.

Two credential classes, each scoped to exactly one project environment: a public key (pub_...), safe to embed in browser code, which can only submit events; and a secret key (sec_...), which lives on your backend only and can read data, manage device trust, and record outcomes.

Policy and webhook management require an authenticated dashboard session — not even a secret key can reach those endpoints. A public key can never record a security outcome or manage anything, by design.

The browser never asserts its own device identity — Sentriq resolves it server-side from independently-hashed signals, with a confidence score and a human-readable reason for every match, new device, or conflict.

Every resource Sentriq returns (devices, events, risk assessments, and more) is identified by an opaque public ID, never the internal database row number — see the identifier format note below.

Subscribe an HTTPS endpoint to risk-decision, device-trust, and outcome events; Sentriq delivers each one asynchronously, signed with HMAC-SHA256 so you can verify it actually came from Sentriq, with automatic retry and backoff on failure.

Outbound requests are hardened against SSRF — a webhook can never be pointed at your own internal or private infrastructure.