# Choose an integration

> Pick the shortest supported path for your application and see which signals each SDK provides.

Canonical page: https://anectico.com/docs/start/choose-integration/


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](/docs/instrument/javascript) | Browser and backend telemetry, errors, replay, identity |
| Django, Flask, FastAPI, Celery | [Python](/docs/instrument/python) | Framework requests, logs, errors, identity |
| Go services | [Go](/docs/instrument/go) | Metrics, traces, logs, errors, identity, gRPC and HTTP services |
| iOS, Android, React Native, Flutter | [Mobile](/docs/instrument/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](/docs/instrument/mobile).

| 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.

[Configure OpenTelemetry](/docs/instrument/opentelemetry)

For custom counters, gauges, and histograms, see
[Record application metrics](/docs/instrument/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.
