Skip to main content
This walkthrough uses the standard OpenTelemetry SDK for your language. No Mirador package is required.
Building a browser app that needs wallet capture? Use the Web SDK instead.

1. Create an API key

In the Mirador dashboard, open your project’s API keys page and create a server key (mir_srv_*). Keep it out of source control.

2. Install an OpenTelemetry SDK

See Pick your language for .NET, Rust, Ruby, PHP, Erlang/Elixir, Swift, and C++.

3. Point it at Mirador

Every OpenTelemetry SDK reads these standard variables:
With the base endpoint set, HTTP exporters append /v1/traces, /v1/metrics, and /v1/logs automatically. For OTLP/gRPC, use otel.mirador.org:4317 and set OTEL_EXPORTER_OTLP_PROTOCOL=grpc.

4. Run your service

Exercise a request. Auto-instrumentation produces spans for inbound HTTP, outbound calls, and database queries with no code changes. Traces appear in the Mirador dashboard within a few seconds.

5. Add your own span

Wrap a meaningful unit of work so the trace reflects your domain, not just transport:

6. Correlate an on-chain action

This is the step that makes a Mirador trace different from a generic OTel trace. When an external action starts, emit a reserved mirador.* span event carrying its identity. Mirador follows the action and stitches the outcome (receipt, bridge fill, confirmation, refund) back into the same trace.
Emit the event only after the external system returns its identity, and use flat attribute keys ('tx.hash', not a nested object). A hint missing a required attribute is preserved as an ordinary span event, so typos stay visible instead of silently dropping.
EVM, Solana, Canton, Safe, Relay, Stripe, and market rates are supported. See Enrichment hints for the full catalog.

Next steps

Pick your language

Setup for every supported runtime

Enrichment hints

Every reserved event and its required attributes

Logs and metrics

Send all three OTLP signals to the same endpoint

Best practices

Naming, attributes, and sampling guidance