Choose an integration
Pick the shortest supported path for your application and see which signals each SDK provides.
On this page
Use an Anectico 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 Anectico 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 | Metrics, traces, logs, errors, identity, gRPC and HTTP services |
| iOS, Android, React Native, Flutter | Mobile | Native crashes, identity, sessions, application events |
Compare capabilities
The mobile SDKs intentionally have a smaller surface than the server SDKs. “Propagation” means the
SDK can attach trace and customer context to a trusted backend request; it does not record full
mobile request traces by itself. All four mobile SDKs also expose startAgentRun for explicit
invoke_agent spans; this is not general-purpose or automatic network tracing. Android's
captureLog writes OTLP logs; captureMessage on mobile records an error/message event, not a
standalone log. See the mobile SDK references.
| Integration | Traces | Metrics | Logs | Errors | Identity and events | Replay |
|---|---|---|---|---|---|---|
| JavaScript / TypeScript | Yes | Yes | Yes | Yes | Yes | Browser only |
| Python | Yes | Yes | Yes | Yes | Yes | No |
| Go | Yes | Yes | Yes | Yes | Yes | No |
| iOS | Propagation and agent-run spans | No | No; messages are error events | Caught and native crashes | Yes | No |
| Android | Propagation and agent-run spans | No | Durable captureLog |
Caught and native crashes | Yes | No |
| React Native and Flutter | Propagation and agent-run spans | No | No; messages are error events | JavaScript/Dart and native crashes | Yes | No |
| Existing OpenTelemetry | Yes | Yes | Yes | As emitted telemetry | Manual attributes | No |
Provider-specific AI wrappers are available in JavaScript, Python, and Go. Browser replay is a separate JavaScript import and permission; it is never enabled by installing the base package.
Install during early access
Anectico is in early access and the public npm, PyPI, Maven, and pub.dev packages are not published yet. Use the package artifact, repository access, or exact install coordinate supplied during onboarding. The Go and iOS SDKs can be installed from an authorized Anectico repository checkout. Do not guess a registry version from the package name; the language guides label registry commands as post-release instructions.
Existing OpenTelemetry setup
Keep your current OpenTelemetry libraries and point their OTLP exporter at Anectico. This is the lowest-change path for traces, logs, and metrics.
OpenTelemetry alone does not automatically create Anectico's cross-signal customer identity. Add the
anectico.distinct_id attribute or W3C baggage at your trusted application boundary if you want
telemetry to appear on customer timelines.
For custom counters, gauges, and histograms, see Record application metrics.
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 Anectico out further.
What not to install
You do not need an Anectico backend, local database, or sidecar. Anectico's SDKs send data to the managed ingestion endpoint. An OpenTelemetry Collector is optional and useful only when it already fits your deployment.