how-to developer public

OpenTelemetry integration

DRC accepts OpenTelemetry trace context so an operator can move from a backend span to the execution, report, replay, and evidence bundle that produced it.

Correlation model


OTel trace/span
  ↔ execution ID
  ↔ report or inbox item
  ↔ browser replay
  ↔ deployment
  ↔ evidence bundle

The correlation is tenant-scoped, deduplicated, and persisted by the hosted ingestion boundary. A trace ID alone is not proof that an execution exists; DRC only displays a verified link after the execution and span identifiers pass validation.

Send OTLP HTTP data

Send OTLP/HTTP JSON or protobuf to the authenticated endpoint:


POST /api/v1/observability/otlp/v1/traces
Authorization: Bearer <tenant-scoped-token>
Content-Type: application/json

Keep trace IDs 16 or 32 hexadecimal bytes and span IDs 8 hexadecimal bytes. Zero-valued IDs, malformed IDs, and spans without an authenticated tenant are rejected.

Find a correlated execution

Use the hosted investigation view or query the execution endpoint with the returned execution ID. DRC exposes service name, span identifiers, timestamps, and deployment/evidence links without exposing raw payloads by default.

Operational guidance

Send batches with a bounded size and retry only retryable responses.
Use an idempotency key for retried batches when the client supports it.
Keep exporter credentials separate from end-user tokens.
Monitor ingestion rejection rate, correlation lag, and duplicate-batch counters.
Treat a missing correlation as an ingestion or metadata problem, not as permission to broaden tenant access.