Skip to main content

​
Overview

Export Orq.ai traces to an observability backend over OTLP/HTTP. Organization administrators configure destinations, choose the Projects to include, and control whether each destination receives metadata or full content. Continuous export and historical export use the same destination configuration.
Through the API, destinations are managed with a Management Key that has the OpenTelemetry destinations permission; regular and project-scoped API keys cannot manage destinations. An update replaces the whole destination: send every request header to keep, with an empty value to retain its stored secret, because omitted headers are removed.

​
Add a destination

  1. Open Settings > Organization > OpenTelemetry.
  2. Select Destination.
  3. Enter the OTLP endpoint URL and any required request headers.
  4. Choose a Content mode and the source Projects, then select Connect destination.
Obtain the OTLP/HTTP endpoint and authentication headers from the receiving backend. Header values remain hidden after saving. Leave an existing header value empty when editing to retain its saved value.

​
Configuration

Metadata only is the default. Full-content export uses the data available to Orq.ai; content removed by masking or retention cannot be recovered through export. Metadata filtering follows the attribute names and types in the OpenTelemetry GenAI conventions. It includes standard booleans and lists, and retains operational fields from recognized GenAI events when available. Existing Orq.ai correlation identifiers are also retained. This mode is more restrictive than the upstream NO_CONTENT setting: free-form descriptions, evaluation explanations, tool schemas, retrieved documents, and references to stored content require Full content. Unknown attributes are excluded from Metadata only.

​
Custom endpoints

Enter the OTLP base URL and any required request headers. Use the advanced traces endpoint setting when the receiver expects a different path from /v1/traces. Use a publicly reachable HTTPS endpoint. Destinations cannot use the Orq.ai platform host. Exported spans carry the telemetry_export.exported attribute, so spans that return to Orq.ai are stored but not sent again by continuous export.

​
Export existing traces

Open a destination’s export action, set From and To in local time, and start the export. Historical exports run in batches and report progress separately from continuous delivery. Each export supports a range of up to 31 days. In Metadata only mode, historical exports include core fields: identifiers, timing, status, operation, provider, model, and token counts. Finish reasons and request parameters are available in continuous export and in Full content historical exports. Only retained data can be exported. If the start time is older than the organization’s trace retention, the export starts from the oldest retained data. Destination providers may restrict the age of accepted spans or require additional setup for historical ingestion. Exporting traces does not delete data from Orq.ai or change retention settings. Historical jobs use the connection configuration captured when queued. Disabling or removing a destination stops its pending exports. After correcting connection settings, start a new export for the required range.

​
Delivery status

Exports can finish successfully, fail, or report partial acceptance. Partial acceptance means the receiver rejected some spans. A receiver’s successful response confirms acceptance at that endpoint; it does not confirm that every span is searchable in the provider’s interface. A destination shows Failing while its latest deliveries fail. Hover the status to see the reason. The status clears after the next successful delivery or after saving the destination. A destination is disabled automatically after 10 failed batches of spans within a minute. A batch counts as failed when the receiver rejects it or its retries run out, so a short outage does not disable a destination. It shows Disabled, with the reason on hover. New spans are not exported and queued spans are dropped until the connection is fixed and the destination is enabled again. Queued continuous deliveries use the destination’s current connection settings, so correcting an endpoint or header also applies to spans waiting to retry. Delivery retries can send a span more than once. Trace and span identifiers remain stable so receivers can recognize duplicates. Correct connection or permission errors before starting another export.