Skip to content
trackbridge

Status & support

Project status

Section titled “Project status”

Pre-1.0 / early access. The SDK is shipping and being used in real production. The dual-send invariants are stable and tested. The non-invariant parts of the API may change between minor versions if we find something worth fixing before the 1.0 lock — they haven’t recently, but the door is open.

If you’re integrating now, expect:

  • The four trackConversion / trackEvent call shapes (browser + server) to stay as documented.
  • The transactionId semantics, click-identifier capture, and Consent Mode v2 behavior to stay as documented.
  • Optional config fields on the constructors may grow; required fields won’t change shape without a major-version bump.

If you’re depending on something that isn’t in the API reference — internal exports, type internals, undocumented behaviors — that’s at your own risk.

Filing bugs and requests

Section titled “Filing bugs and requests”

The issue tracker is the primary support channel: github.com/trackbridge/sdk/issues.

A useful bug report includes:

  • The SDK version (bun pm ls @trackbridge/browser or equivalent for your package manager).
  • The framework and version (Next.js 15.x, Vite 5.x, etc.).
  • A minimal reproduction, ideally a small repo or a stripped-down code snippet that can be copy-pasted into the examples/nextjs-demo.
  • The exact console.warn output (with debug: true) — see the Warning catalog to identify the failure class.
  • For Ads API failures, the response body. With debug: true on createServerTracker, this is logged alongside the status code.

Issues that include the above generally get a response within a few business days. Issues without are slower — we ask for the missing info before triaging, which adds a round-trip.

Asking questions

Section titled “Asking questions”

For “is this the right approach” or “how do I X with Trackbridge”, open a discussion: github.com/trackbridge/sdk/discussions. Issues are reserved for actual defects and concrete feature requests so the queue stays manageable.

If your question is documentation-shaped — “I read X and it didn’t explain Y” — that’s an issue on this docs repo: github.com/trackbridge/docs/issues. Documentation gaps get prioritized; we’d rather rewrite a confusing page than answer the same question five times.

Security disclosures

Section titled “Security disclosures”

If you find a security issue (credential leak in browser bundle, OAuth token mishandling, etc.), email security@trackbridge.dev with a description and reproduction. Do not file a public issue.

We respond within 72 hours. Coordinated disclosure is appreciated.

Direct contact

Section titled “Direct contact”

For commercial conversations — engagements, support contracts, integration partnerships — hi@trackbridge.dev. Public-facing technical questions should go through the issue tracker or discussions; email is for things that don’t fit those channels.

What we don’t have (yet)

Section titled “What we don’t have (yet)”
  • A Slack or Discord. The issue tracker is the only async channel today; the team is small enough that a chat surface would be empty most of the time.
  • Paid support tiers. The SDK is MIT and the team is reachable; commercial engagements are negotiated case-by-case.
  • A public status page for SDK availability. The SDK has no hosted runtime — it runs in your bundle and your servers. There’s nothing for us to be “up” or “down”.