Choose an integration

Use a Teml SDK when you want customer identity, errors, and application telemetry to connect automatically. Use OpenTelemetry when you already have instrumentation and want to send it to Teml without replacing it.

Application SDKs

Application	Start here	Best for
Browser, Node.js, React	JavaScript / TypeScript	Browser and backend telemetry, errors, replay, identity
Django, Flask, FastAPI, Celery	Python	Framework requests, logs, errors, identity
Go services	Go	Traces, logs, errors, identity, gRPC and HTTP services
iOS, Android, React Native, Flutter	Mobile	Native crashes, identity, sessions, application events

Teml is in early access. The Go and iOS SDKs are source-installable; other SDK builds are supplied during onboarding until their public registry releases are available. Use the install coordinate provided in your onboarding message rather than guessing a package version.

Existing OpenTelemetry setup

Keep your current OpenTelemetry libraries and point their OTLP exporter at Teml. This is the lowest-change path for traces, logs, and metrics.

OpenTelemetry alone does not automatically create Teml’s cross-signal customer identity. Add the teml.distinct_id attribute or W3C baggage at your trusted application boundary if you want telemetry to appear on customer timelines.

Configure OpenTelemetry

Choose the first application carefully

Start with one customer-facing journey, not every service. Good first choices are checkout, onboarding, search, or the main AI workflow. The first integration should be able to produce:

• a stable customer ID;
• at least one request trace;
• a captured error; and
• browser replay when the journey has a web interface.

That is enough to validate the complete investigation workflow before rolling Teml out further.

What not to install

You do not need a Teml backend, local database, or sidecar. Teml’s SDKs send data to the managed ingestion endpoint. An OpenTelemetry Collector is optional and useful only when it already fits your deployment.