OpenTelemetry endpoint
Openlayer accepts OTel traces at the following endpoint:https://api.openlayer.com/v1/otel.
This endpoint uses the OTLP protocol and expects telemetry data in protobuf format over HTTPS.
Most OTel-instrumented SDKs use this format by default, but be sure to check your SDK’s documentation
to confirm your setup.
To send OTel data to Openlayer, configure your SDK to use the endpoint above and include
the correct authentication headers. This is typically done using the environment variables shown below.
If you use an OTel Collector that requires signal-specific environment
variables, the export endpoint must be
https://api.openlayer.com/v1/otel/v1/traces.Property mapping
When Openlayer receives OTel data, it transforms it into its own trace format. This involves mapping properties from the GenAI semantic convention and popular frameworks into Openlayer’s trace data model.Sessions and users
Openlayer reads theopenlayer.session.id and openlayer.user.id span attributes to
group traces into sessions and users. If your whole
request is traced in one process, setting the attributes on your root span is enough:
BaggageSpanProcessor stamps them onto each span the
process creates. Instrumented HTTP clients forward baggage alongside traceparent, so
downstream services need no Openlayer-specific code.
Distributed tracing across services
OpenTelemetry propagates trace context (the W3Ctraceparent header) across service
boundaries by default when both sides run instrumented HTTP clients and servers. For a
system of multiple traced services — for example, agents calling each other — you have
two options:
- One pipeline for all services: point every service’s exporter at the same
x-bt-parentpipeline, and their spans merge into a single trace that crosses process boundaries. - One project per service: point each service at its own project’s pipeline. With trace context propagating exactly as before, Openlayer promotes each service’s part of the trace into a full record in its own project and links the records directionally — the caller’s record shows a Continues in … chip and the callee’s record shows a Called from … chip, each deep-linking to the other.
Per-project linking relies on remote-root promotion, which is enabled per
workspace — reach out to your Openlayer contact to turn it on. For a complete
worked example (including Google ADK agents), see the A2A protocol
integration.