Methods

This is the entire browser SDK. You call fidero.track to send an event, fidero.page for a page view, and a handful of methods to manage identity and consent.

The API stays small because the browser’s only job is to collect events. Once a call lands, Fidero takes over on the server: it shapes the event for each destination, drops duplicates and handles delivery.

init() itself is covered on Installation and Configuration – this page is everything you call afterwards.

Note

fidero.init() is asynchronous: it fetches your project configuration and gets the SDK ready. Calls you make before it finishes (track, page and the rest) are queued, then replayed in order once it’s done, so you don’t need to wait. Wait only when you need to read SDK state immediately after init (see The ready promise).

track()

Sends an event. track takes a single object: the event name and its properties, plus optional identity and delivery options.

fidero.track({
  event: "subscription_started",
  userId: "user_2c9d47",
  properties: {
    transaction_id: "sub_8Kw3P9",
    value: 12.99,
    currency: "GBP",
  },
});

event string required

The event name. Use a standard name from fidero.Event so naming stays consistent across your stack.

properties object

Properties for the event, such as value, currency and transaction_id.

userId string

Associates the event with a known user. The visitor’s earlier anonymous activity then links to their profile.

traits object

User traits to set or update before the event is sent, such as email or name.

options object

Delivery options.

skipServerRequest boolean default: false

Run your client-side integrations and mark the event as handled, without sending it to Fidero’s server. Use it when the same event is already sent from your backend. Both promises still resolve.

Tip

Give every conversion a transaction_id. When the browser and your server both report the same purchase, Fidero keeps one and drops the other, so every destination counts the purchase once. The guarantees behind that are on Guarantees & coverage.

track returns a promise that resolves once the event is stored in the browser’s delivery queue. From that moment the event survives a navigation. Fidero retries delivery with backoff, and drains the queue on a later page view if the first attempts don’t land. Configuration has the retry and queue limits.

When you need the server’s confirmation on the same page, use .delivered, a second promise attached to the one track returns. It resolves once Fidero has acknowledged the event. Neither promise resolves with a value – a call that fails rejects instead.

// safe to navigate away once this resolves
await fidero.track({ event: "account_created", userId: "user_2c9d47" });

// waits for the server to acknowledge the event
await fidero.track({ event: "trial_started", userId: "user_2c9d47" }).delivered;

Tip

Firing an event just before a redirect? await fidero.track(…), then navigate. Once it resolves, the event is stored and finishes delivering on its own. Where the browser gives Fidero no storage to use, the event is never stored and Fidero warns in the console. Await .delivered before navigating instead.

page()

Records a page view. The install snippet calls fidero.page() once on first load.

// typical – capture the current page
fidero.page();

// override an auto-captured field
fidero.page({
  properties: {
    page_title: "Pricing",
  },
});

properties object

Custom properties to send with the page view, plus overrides for any auto-captured field: page_title, page_url, page_path, page_referrer, page_search.

If a personal detail like an email address ends up in a captured URL’s query string, Fidero scrubs it server-side before delivery. Security & compliance covers what’s recognised and what stays your responsibility.

Note

In single-page apps, call fidero.page() after each route change. The install snippet records the first page view, but client-side navigations don’t reload the page, so later views are yours to send.

updateIdentity()

Sets or updates who the current visitor is, outside of a track call. Pass a userId, traits or both.

fidero.updateIdentity({
  userId: "user_8f3a91",
  traits: {
    email: "ada@example.com",
    name: "Ada Lovelace",
  },
});

userId string

The user’s unique ID. Fidero merges the visitor’s earlier anonymous history into their profile.

traits object

Traits to store on the profile, such as email, name or phone.

Note

Fidero generates and manages the anonymous ID for you. track and updateIdentity do accept an anonymousId, but passing one yourself is rare: it’s for when your backend or another domain already holds the visitor’s anonymous identity. See Connecting anonymous → server.

updateConsent()

Tells Fidero the visitor’s current consent. Keys are consent categories and values are booleans. This works only when consent management is enabled in your project configuration.

fidero.updateConsent({
  analytics: true,
  advertising: false,
});

consent object required

The categories to set. Recognised categories: essential, functional, analytics, advertising, dataSharing. essential is always on.

Caution

With a custom consent solution, you must call updateConsent() on every page load, so Fidero starts each page with the correct consent state.

Consent & privacy covers how Fidero applies consent per destination: the effective-consent model, overrides and queue-and-replay.

reset()

Clears the current user’s userId and traits, along with the cached integrations state, then starts a fresh anonymous session. The typical use is logout.

await fidero.reset();

regenerateAnonId boolean default: true

Generate a fresh anonymous ID as part of the reset. Set it to false to clear the user’s identity but keep the current anonymous ID.

The ready promise

fidero.ready is a promise that resolves once the SDK has fetched your configuration, loaded your integrations and replayed any queued calls. fidero.init() returns the same promise. You need it only to read SDK state right after init, for example the fidero.Event constants. It rejects if initialisation fails.

await fidero.init("YOUR_PROJECT_ID");
// SDK is ready here

// or, without awaiting init:
fidero.ready.then((fidero) => {
  // SDK is ready here
});

Reading current state

Two synchronous getters read what the SDK currently holds.

getIdentity()

Returns the current identity: anonymousId, userId and traits.

const { anonymousId, userId, traits } = fidero.getIdentity();

getConsent()

Returns the visitor’s current consent state, as categories mapped to booleans. Until consent has been set, it returns null rather than a default state.

const consent = fidero.getConsent();

Standard event names

You don’t invent event names: Fidero has a standard set. fidero.Event exposes them as constants, so you avoid typos and get the same names everywhere: fidero.Event.PURCHASE_COMPLETED is "purchase_completed". Use page() for page views rather than an event name.

fidero.track({
  event: fidero.Event.PURCHASE_COMPLETED,
  properties: { transaction_id: "ord_7Kp2", value: 49.0, currency: "GBP" },
});

The full set, and why naming is decided for you, is on Standard events.

Related

Configuration The init() options, and why the rest of your configuration lives server-side.

Standard events Every standard name Fidero recognises, browser and server.

Server-side events Renewals, webhooks and backend conversions – events the browser never sees.

For why the server holds each customer’s context in the first place, see the platform overview.