Installation
The core SDK has zero dependencies and works with any runtime that supports the Web Fetch API (Node.js 18+, Bun, Deno, Cloudflare Workers).
Client setup
No configuration is required — the SDK defaults to the production runner.
Configuration options
Fetching personalised content
Single workflow
Multiple workflows in parallel
Run options
Handling the response
run() returns a RunResult with a discriminated union body:
RunResult fields
Click tracking
Click tracking must always be set up after display. The flow is: fetch content → display it to the user → track clicks when they interact. Every content display should have a corresponding click tracking mechanism, otherwise you lose attribution data.
Every RunResult includes a redirectionUrl and a trackClick() callback. This ensures click tracking is always recorded — devs must use one of the two patterns below.
Option 1: Redirect link (recommended for CTAs)
Use redirectionUrl as the href on your call-to-action links. The browser handles everything — the runner tracks the click and 302-redirects to the final destination.
Option 2: Server-side fire-and-forget
Call result.trackClick() when you control navigation and want to track the click in the background. It calls the runner click endpoint with redirect: manual and swallows all errors — it never throws.
No arguments needed — the callback is pre-bound to the result’s redirectionUrl.
Identity helpers
Extracts the Reelevant user ID from cookies. Priority: rlvt_clientId > rlvt_tmpId.
generateTmpId()
Generates a new anonymous temporary ID, matching the format used by the client-side tracker.
Fallback strategies
Configure how the SDK handles timeouts and errors:
Request flow
Express example
Constants
The SDK exports commonly used constants: