@fixback/node reference

Exports

import {  init,  captureException,  captureMessage,  setUser,  mintHostIdentity,} from "@fixback/node";// framework adapters (optional, subpath imports):import { fixbackRequestContext, fixbackErrorHandler } from "@fixback/node/express";import { FixbackModule } from "@fixback/node/nestjs";

init(options)

Call once, as early in the process as possible.

Set the two per-signal flags to override the umbrella individually — e.g. { autoCapture: false, captureUnhandledRejection: true } installs only the rejection handler.

Transport tuning

Sensible by default; reach for these only when your traffic shape asks for it.

The single init call also wires a batched secret-key transport (backs off on 429, honouring Retry-After) and process-level uncaughtException / unhandledRejection capture that never changes your process's exit behaviour. Each error carries the instant it was captured, so a batch flushed seconds later still records when every error happened.

Capture functions

mintHostIdentity(options)

A Host identity is the escape hatch for a product that already knows who its users are: your server mints a short-lived token from one of an environment's secret keys and hands it to a capture SDK (web or Expo) as its hostIdentity. Fixback verifies it and tiers the Reporter — Internal when the token's email is an Org Member, otherwise Invited — with no Connect round trip. A verified Host identity whose email matches a Fixback Account resolves to that same person, so the host and the platform are one Reporter.

It verifies only against the secret keys of the environment whose publishable key that capture SDK presents, so sign it with a key of the same environment — a staging server's secret mints nothing production accepts.

import { mintHostIdentity } from "@fixback/node";// On your server, for a user you already authenticated:const hostIdentity = mintHostIdentity({  secretKey: process.env.FIXBACK_SECRET_KEY!, // sk_… — never ship it to a client  subject: user.id,                            // your stable id for the user (JWT sub)  email: user.email,                           // optional — Member ⇒ internal tier  expiresInSeconds: 3600,                       // optional — defaults to one hour});// Hand it to a capture SDK as its hostIdentity option://   web:  Fixback.init({ key: "pk_…", hostIdentity })//   expo: <FixbackProvider options={{ key, origin, hostIdentity }} />

The recipe is an HS256 JWT signed with sha256(secretKey) — the value Fixback stores for the key and verifies against (the secret plaintext is shown once at issuance and never kept). This helper is that recipe, so you never hand-roll JWT signing. Issue and revoke secret keys on the Project's Keys page, for the environment picked in the switcher; a revoked key stops verifying at once.

Express adapter — @fixback/node/express

NestJS adapter — @fixback/node/nestjs

The Correlation id

The request-context middleware (either adapter) gives every request one id, and errors captured during the request carry it. It takes the first source that has one:

1. the trace id of an inbound W3C traceparent header — what the browser SDK sends on your page's same-origin requests and to the origins listed in its propagateTo, and what the Expo SDK sends to the origins listed in its own;
2. the requestIdHeader — x-request-id unless you configured another;
3. a freshly minted id.

A malformed traceparent is ignored whole, never partly used, and the next source applies. When the page's request carried the id, the server Issue's request row and the browser Issue's network row show the same Correlation id, and the server Issue lists the page Issues it was seen from — with their replay — while each of those names it as the server error behind its request. Both capture SDKs send the sampled flag (01), so a parent-based OpenTelemetry sampler on this server records those requests rather than dropping them.