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
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 andlocalStorage, up to 1000) and flushed in batches to keep requests few and small.
Batched in chunks of 100
Batched in chunks of 100
Events post to
/ingest/batch with keepalive: true so in-flight requests survive navigation. Since SDK 1.7.1 the queue is split into chunks of 100 events, the most the server accepts in one batch, and the chunks are sent one after another.Rejected events are logged, not retried
Rejected events are logged, not retried
Failed events are dropped instead of requeued, so one bad event can never loop forever. Since 1.7.1 a rejection (HTTP 400) is logged in the console with the server response and the rejected codes. A batch accepted in part answers HTTP 207 and lists the refused events in
failedEvents. See Troubleshooting.Unload-safe
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
Safe to retry
Each event carries a unique id and conversions carry a
conversionId, so the server absorbs retries without doubling records, and the unload time sendBeacon flush never duplicates visitor activity.Timestamped
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
Every request is authenticated with the
X-Orwel-Key header (your public or development key), which maps to a workspace. Events are always scoped to that workspace, so your data never mixes with another’s. These keys can only write; reading uses API keys.