CDN & Infrastructure

How the SDK is distributed and how events reach the server — batched, unload-safe, and idempotent.

The SDK ships as the orwel npm package with a self-contained UMD build (~60 KB, dependencies bundled). Use it from a CDN with zero build step, or install it into any bundler-based app.

Distribution

CDN

<script src="https://cdn.jsdelivr.net/npm/orwel@1/dist/orwel.umd.js"></script>

The UMD bundle attaches the SDK to window.orwel; the ESM build is used by bundlers automatically. Both are served by any npm CDN (jsDelivr, unpkg).

The pipeline

How events reach the server

The SDK never blocks your app. Events are queued in memory and flushed in batches to keep requests few and small.

Batched + keepalive

Events post to /ingest/batch with keepalive: true so in-flight requests survive navigation.

Unload-safe

On beforeunload / tab hide, the queue is flushed via navigator.sendBeacon (falling back to a sync request) so the last events aren’t lost.

Safe to retry

Each event carries a unique id, and the batch endpoint is built to absorb retries without doubling records — so transient network failures and the unload-time sendBeacon flush never produce duplicate visitor activity.

Timestamped

Every event is stamped with an ISO timestamp at the moment it’s queued; sessions track their own startedAt, updatedAt, and finishedAt. Useful for ordering, latency analysis, and reconstructing real-time journeys.

Ingest endpoints

Endpoint	Purpose
POST /ingest	Single event / session / conversion.
POST /ingest/batch	A batch of events (the common path).
POST /visitor-resolve	Resolve a stable visitor id from a fingerprint.

Every request is authenticated with the X-Orwel-Key header, which maps to a workspace. Events are always scoped to that workspace — your data never mixes with another’s.