Installation
Le SDK core n’a aucune dépendance et fonctionne avec tout runtime prenant en charge la Web Fetch API (Node.js 18+, Bun, Deno, Cloudflare Workers).
Configuration du client
Aucune configuration n’est requise — le SDK utilise par défaut le Runner de production.
Options de configuration
Récupérer du contenu personnalisé
Un seul Workflow
Plusieurs Workflows en parallèle
Options d’exécution
Traiter la réponse
run() renvoie un RunResult dont le body est une union discriminée :
Champs de RunResult
Tracking des clics
Le tracking des clics doit toujours être configuré après l’affichage. Le flux est le suivant : récupérer le contenu → l’afficher à l’utilisateur → suivre les clics lorsqu’il interagit. Chaque affichage de contenu doit avoir un mécanisme de tracking des clics correspondant, sinon vous perdez des données d’attribution.
Chaque RunResult inclut une redirectionUrl et un callback trackClick(). Cela garantit que le tracking des clics est toujours enregistré — les développeurs doivent utiliser l’un des deux patterns ci-dessous.
Option 1 : Lien de redirection (recommandé pour les CTA)
Utilisez redirectionUrl comme href sur vos liens de call-to-action. Le navigateur gère tout — le Runner suit le clic et effectue une redirection 302 vers la destination finale.
Option 2 : Fire-and-forget côté serveur
Appelez result.trackClick() lorsque vous contrôlez la navigation et souhaitez suivre le clic en arrière-plan. Il appelle l’endpoint de clic du Runner avec redirect: manual et absorbe toutes les erreurs — il ne lève jamais d’exception.
Aucun argument nécessaire — le callback est pré-lié à la redirectionUrl du résultat.
Helpers d’identité
Extrait l’ID utilisateur Reelevant des cookies. Priorité : rlvt_clientId > rlvt_tmpId.
generateTmpId()
Génère un nouvel ID temporaire anonyme, au format utilisé par le tracker côté client.
Stratégies de repli
Configurez la manière dont le SDK gère les timeouts et les erreurs :
Flux de requête
Exemple avec Express
Constantes
Le SDK exporte des constantes couramment utilisées :