@biqli/analytics runs only in browsers and accepts only a biqli_pk_... publishable key.
https://biq.li/sdk/dist/auto.global.js with a data-publishable-key attribute. See the HTML guide.
Configuration
Cookie options
The SDK writes
bq_id as a first-party cookie. If the browser rejects that cookie, it uses controlled local-storage fallback where available.
Retry queue defaults
Instance methods
storeStripeSession() is available for Biqli’s browser-to-Stripe attribution adapter. New custom payment implementations should normally persist bq_id in their own backend and send sales with the server SDK.
Tracking inputs
Client click
Shared customer identity
Every lead and sale accepts these fields:
Lead-specific fields are
eventName (required), eventId, and eventQuantity (default 1).
Sale-specific fields are amount (required integer minor units), currency, eventName, paymentProcessor, invoiceId, eventId, and leadEventName.
Use a stable lead eventId. For a sale, use stable paymentProcessor and invoiceId values whenever they exist.
Results and errors
A successful tracking call returns the created or replayed event, customer, click, link, andrequest_id. During a retryable browser outage it can instead return:
BiqliError with code, status, requestId, details, and retryable properties. A queued result is not proof that the server has received the event; it means the SDK will retry within its configured queue limits.
Module helpers
inject() replaces and tears down the previous injected instance. Use the class directly when your application owns instance lifecycle.
React exports
BiqliProvider.

