SDK family and availability: browser, server and mobile
Noxtica ships one public browser surface, the collector script served from your collector host, and a family of SDKs and tooling around it. This page says what each part is for, which version the source holds on 2026-10-27, and how you get access to the parts that are not public. Use it to decide what to ask for and what to build on plain HTTP.
Key points
- The script tag needs no SDKThe collector script served from your collector host is the public browser surface. Every other package in the family is private and available through your account team.
- Wrapper not on the public registryThe @noxtica/sdk browser wrapper is at 0.3.0 in source. The public registry answered E404 on 2026-10-27, so there is no install command.
- Wrapper and loader version apartWrapper 0.3.x needs loader 3.8.0 or newer and targets 3.8.1. Wrapper 0.2.x works with any loader and targets 3.5.x to 3.7.x.
- Verify protected actions over HTTPNone of the seven server SDKs wraps POST /v1/protected-actions/verify. Call it with plain HTTP and a key that has the read:device scope.
What it is
Availability: Evaluation access for the browser collector script (device intelligence). Availability depends on your plan, role and the modules enabled for your organisation. Every package, collection and description file in the table below is distributed privately. For access, ask your account team.
Three statements hold for the whole family:
- The script tag from Install and Browser Runtime needs no SDK. Everything on the other pages of this section works with the tag alone.
- None of the SDKs is required to call the Server API. Plain HTTP with a Server API key works; see Server API overview.
- The
@noxtica/sdkbrowser wrapper is not installable from the public registry: the registry answeredE404on 2026-10-27. Treat any copy of a Noxtica package that you find in a public registry as unverified, and do not install it.
Prerequisites
- A Noxtica account and an account team contact. See Contact.
- For a server SDK or plain HTTP: a Server API key (
sk_prod_…) created in Backoffice, kept on your server. See Authentication. - For the browser: a domain and its Site Key. See Domains, site keys and the install card.
- For a mobile app: a backend of your own that relays attestation to Noxtica. The mobile SDKs never hold a Server API key.
Steps
1. Choose what you need
| Surface | What it is for |
|---|---|
Browser collector script (noxtica-collector-core.js and noxtica-collector-extensions.js) | Collects the browser signals, handles consent, runs protected actions. A script tag; no package. |
@noxtica/sdk (browser wrapper) | A typed wrapper around the script: init(), a client, a verdict helper that fails closed on a suppressed verdict, and React, Next.js and Vue helpers. Also helpers to build your own Web KYC capture flow. It never contains the collector; the script always comes from your collector host. |
| Server SDKs (Node.js, Python, Go, PHP, Java, .NET, Rust) | Typed clients for the Server API (/v1/*), in most languages offline verification of signed result envelopes, and in some languages KYC session helpers and framework middleware. Coverage differs per language; read the README you receive. |
| Mobile SDKs (Android, iOS) | App and device attestation clients, KYC capture helpers, and real-user monitoring modules. The device talks to your backend, and your backend relays to Noxtica. |
| OpenAPI descriptions | Machine-readable descriptions of the backend API (v1, the routes that are not identity verification), the KYC, KYB and KYM API (kyc) and the Pulse customer, sign-in and device API (pulse). The v1 description includes POST /v1/protected-actions/verify. The public operations of each are published as /docs/api/openapi/<api>.json and .yaml, and together as openapi.json; the complete source files come with the deliveries from your account team. |
| Postman collections | A hand-written collection for the collector (assets, browser API, backend API, legacy routes) and a generated collection for the backend API, with local and prod environments that hold placeholders. |
2. Read the versions and availability
| Surface | Version in source on 2026-10-27 | Runtime floor | Status |
|---|---|---|---|
| Browser collector script | Loader 3.8.1 (window.NoxticaCollector.VERSION) | A browser with WebAssembly and Web Workers for the engines | Served from your collector host. Documented in this section. |
@noxtica/sdk | 0.3.0 (targets loader 3.8.1, needs 3.8.0 or newer) | A browser; init() rejects on a server | Private. Not on the public registry. |
| Node.js SDK | 0.1.1 | Node.js 22 | Private. |
| Python SDK | 0.1.1 | Python 3.10 | Private. |
| Go SDK | 0.1.1, plus an OpenTelemetry module at 0.1.1 | Go 1.25 | Private. Version 0.1.0 is retracted; do not use it. |
| PHP SDK | 0.3.0 | PHP 8.2 | Private. |
| Java SDK | 0.1.1 | Java 17 | Private. |
| .NET SDK | 0.2.2 | .NET 8 | Private. |
| Rust SDK | 0.1.0 | Rust 1.82 | Private. |
| Android SDK | 0.3.2 | Android 7.0 (API level 24) | Private. |
| iOS SDK | 0.2.13 | iOS 15 | Private. |
| OpenAPI descriptions | Each description file carries its own info.version | Not applicable | The public operations are published at openapi.json. The complete source files are private. |
| Postman collections | Each collection carries its own version | Not applicable | Private. |
“Private” means the source is not published and the packages are not in a public registry. Access is arranged through your account team. The wrapper’s own notes say that its 0.x versions can carry a breaking typing change in a minor release; read the changelog that comes with any package before you upgrade.
3. Ask for access
Ask your account team, or use Contact. Say:
- Which surface and which language or platform.
- Which environment: evaluation or production.
- The loader version your pages run, from
window.noxtica.v, if you ask for the browser wrapper.
Do not copy credentials, package names or build output from another team’s repository or from an older example.
4. Match the wrapper to the loader
The wrapper and the loader version separately. The script on the page is the loader; the wrapper only types and drives it.
@noxtica/sdk | Loader it needs | Targets | What the pairing changes |
|---|---|---|---|
0.3.x | 3.8.0 or newer | 3.8.1 | loadExtensions() resolves a result object. The consent snapshot gains the optional modeResolved. On loader 3.8.0, modeResolved is undefined: wait while it is false, never for true. |
0.2.x | any | 3.5.x to 3.7.x | init() injects the core script by default. A boolean loadExtensions() is normalised to { ok, loaded }. |
Against a loader older than 3.8.0, the wrapper turns the boolean into { ok: true, loaded: [] } or { ok: false, reason: 'unknown', code: 'legacy_loader' }. The full loader history is in SDK Changelog.
5. Keep the key types apart
| Key | Where it lives | Used for |
|---|---|---|
Site Key (pk_…) | Public; in the browser tag | Identifies the domain for /client/* calls from the registered origin. |
Server API key (sk_prod_…) | Your server only | /v1/* calls, including protected-action verification. |
A server key in browser code, a mobile app resource, a URL or a client-visible log is a leak. The mobile SDKs are built so that the device never holds one.
6. Verify protected actions over plain HTTP
None of the seven server SDKs has a wrapper for POST /v1/protected-actions/verify. Call it with any HTTP client, as shown in Protected actions. The call needs a key with the read:device scope. The other Server API calls are in the API reference.
curl -X POST "https://collect.noxtica.com/v1/protected-actions/verify" \
-H "Authorization: Bearer sk_prod_your_api_key" \
-H "Content-Type: application/json" \
-d '{"requestId":"<uuid from the browser>","action":"login"}'Choose what you need
Pick between the script tag, the browser wrapper, a server SDK, a mobile SDK, OpenAPI files and Postman collections.
Read versions and status
Source versions on 2026-10-27 are listed per surface. All packages are private; the loader is served from your collector host.
Ask for access
Contact your account team with the surface, the language or platform, the environment and your loader version.
Match wrapper and loader
Check that window.noxtica.v meets the minimum loader for your wrapper version.
Keep key types apart
Site Keys are public in the browser tag. Server API keys stay on your server, and mobile apps relay through your backend.
Verify over plain HTTP
Call POST /v1/protected-actions/verify from your backend with a Bearer key. A fresh id returns 200 and a repeat returns 409.
Verify it works
- Browser script.
window.NoxticaCollector.VERSIONandwindow.noxtica.vreport the loader version, andPOST /client/tokenanswers200. - Wrapper, when you have it. The loader version meets the minimum in step 4, and
loadExtensions()resolves an object that hasok. - Server. An authenticated request to the Server API returns a result. Handle
401,403,404and429explicitly. See Backend Integration. - Protected actions. The verify call returns
200for a fresh id and409for the same id again.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
The package manager says @noxtica/sdk is not found (E404) | The wrapper is not on the public registry | Use the script tag, or ask your account team for access. |
loadExtensions() resolves reason: 'unknown' with code: 'legacy_loader' | The wrapper is newer than the loader on the page | Use a loader of 3.8.0 or newer. |
init() rejects with a browser-only error | It ran on a server | Guard shared code with isBrowser(), or load the script tag in the HTML. |
The wrapper’s setConsent takes only 'granted' or 'denied' | It maps to the legacy analytics form | Use window.noxticaClient.setConsent({ … }) for categories. |
init() rejects a pinnedLoader.version | pinnedLoader.version needs script: 'combined' | Pin the core with scriptUrl and pinnedLoader.integrity. |
| A suppressed verdict reads as zero | Code used verdict.score ?? 0 | Use isHighRisk(verdict), which treats a verdict without a score as high risk. |
| A Go build pulls version 0.1.0 | That version is retracted | Pin version 0.1.1 or newer. |
| There is no server-SDK call for protected-action verification | No facade exists | Use plain HTTP, step 6. |
| A mobile app needs a key | Mobile SDKs relay through your backend | Keep the Server API key on your backend. |
Related
- Install and Browser Runtime: the script tag.
- Client API, events and the command queue: what the wrapper drives.
- Protected actions: the verify call over HTTP.
- Device and app attestation: the mobile attestation relay.
- Server API overview, Authentication and API reference: plain HTTP access.
- SDK Changelog: loader releases and the wrapper pairing table.
- Developer overview: the short path through the browser, server, and policy guides.