SDKs
Torno’s SDKs do two jobs: collect events and assign Change variants. Both are built around a single constraint — no Torno network call in your customer’s request path.
Packages
| Package | Role |
|---|---|
@torno/sdk-core |
Browser core: Subject minting and storage, first-touch capture, consent, signed-bundle verification and cache, local assignment, batching transport, and the four calls. Under 10 KB gzipped, enforced by a build gate. |
| React, Astro, Vue, Svelte adapters | Thin Provider, Change, Expose, and Goal idioms over the core. |
| Node and Python SDKs | Server-side collection with HMAC signing, deterministic event IDs, cached assignment, and a Stripe Subject-metadata helper. |
| Next.js, Cloudflare Workers, Netlify middleware | Page-variant route assignment and cookie handoff at the edge. |
The four calls
| Call | What it does |
|---|---|
track |
Record an event with properties |
identify |
Link the Subject to a known Customer |
expose |
Record that this Subject saw a Change variant — the moment measurement starts |
goal |
Record a goal event that Changes and Experiments count |
npm install @torno/sdk-core
The framework adapters wrap the same four calls in Provider, Change, Expose, and Goal idioms, and torno init wires whichever package fits the stack it detects — see Getting started for the wiring flow.
The browser core also observes declaratively: data attributes and framework components emit expose only after the element is actually viewable, so a variant below the fold is not an exposure. Goal calls and the feedback widget stay explicit.
Consent and the Subject key
The Subject key is first-party and PII-free. Consent state controls storage, collection, assignment, and ad-related fields — not just whether events send. CMP adapters for TCF, Google Consent Mode, OneTrust, Cookiebot, and Usercentrics load lazily. Events batch and retry with stable IDs, so flaky networks do not create duplicates, and use the beacon path when a page is closing. Details in Identity and privacy and Event collection.
Local assignment, fail-open
Assignment never waits on Torno. The SDK fetches signed assignment bundles in the background — sync target 60 seconds or less — verifies key, signature, and version, caches the bundle, and buckets locally and deterministically. Assignment is sticky per Subject.
If the bundle is missing, stale, or tampered with, or Torno is unreachable with no valid cache, the SDK returns control or pass-through. Host-page errors are contained rather than propagated. Edge middleware follows the same contract and adds no Torno call to the request path. The bundle format and delivery rules live in Changes and delivery.
Quality gates
Two gates keep the suite honest:
- Size: the JS core is budgeted under 10 KB gzipped, enforced in CI — the build fails before your page slows down.
- Conformance: a shared suite covers consent vectors, deterministic IDs, assignment and fail-open behavior, cross-language Node and Python parity, edge middleware contracts, a browser support matrix, and adapter types. Types are generated from the same schema contracts the platform uses.
Honest notes
Edge middleware for Next.js/Vercel, Cloudflare Workers, and Netlify is exercised against each runtime’s contract in the shared conformance suite — sticky bucketing, pass-through, and cookie handoff are verified in fixtures per target. Treat per-platform behavior as adapter-based conformance rather than per-host production certification.