jentry now speaks OpenTelemetry: OTLP traces, span trees, and APM without a vendor SDK

What shipped

• A native OTLP/HTTP endpoint per project — /api/<projectId>/otlp/v1/traces — accepting both encodings: http/protobuf (the SDK default, decoded with a dependency-free wire-format parser) and http/json.
• Real span trees in the trace waterfall: children nest under parents via parent_span_id, render parent-first, and errored spans show up red.
• Your OTel spans feed the same performance brain as Sentry-SDK spans: N+1 query detection, N+1 API calls, slow-query issues — with span evidence, repeat counts and estimated time saved.
• Semantic conventions map onto the op families the UI already understands: db.system, http.request.method, messaging.system, service.name, deployment.environment, service.version.

The two-minute setup

export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://jentry.app/api/<projectId>/otlp/v1/traces"
export OTEL_EXPORTER_OTLP_HEADERS="x-jentry-key=<your project key>"

That is the entire integration. No protocol switch (protobuf just works), no collector required (though a Collector pointing its otlphttp exporter at the same URL works too), and gzip bodies are handled.

Why local-root mapping

jentry follows the model proven by Elastic APM: within each resource batch, a span whose parent is absent becomes a transaction, and its in-batch descendants become that transaction's spans. Cross-service traces stitch back together by trace id, so two instrumented services show up as one waterfall.

Honest scope

This is traces-first: OTLP metrics and logs aren't ingested yet (custom metrics have their own API). Error events still ride the Sentry-compatible path — which means OTel traces and your existing Sentry SDKs coexist in the same project, sharing quotas, rate limits and alerts.