> ## Documentation Index > Fetch the complete documentation index at: https://docs.orq.ai/llms.txt > Use this file to discover all available pages before exploring further. # OpenTelemetry export > Export traces to an external observability backend with organization-level destinations and project controls. ## 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. > [!NOTE] > > Through the API, destinations are managed with a [Management Key](https://docs.orq.ai/ai-studio/organization/management-keys.md) 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 | Setting | Description | | - | - | | Name | Optional label to distinguish destinations. Defaults to the endpoint host. | | OTLP endpoint URL | Public HTTPS base URL. The form adds the `/v1/traces` path unless already present. When using the API, set `endpoint_url` to the full traces URL. | | Request headers | Optional authentication and routing headers required by the receiver. Enter complete values, including `Bearer` or `Basic` when required. | | Content mode | **Metadata only** exports standard operational fields such as identifiers, timing, status codes, request parameters, finish reasons, agent and workflow names, and token usage breakdowns. **Full content** also includes available message and tool content. | | Projects: All | Include all Projects in the organization, including newly created Projects. | | Projects: Custom | Include only the selected Projects. | | Projects: All except | Include all Projects except the selected Projects. | **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](https://github.com/open-telemetry/semantic-conventions-genai/tree/3fe84604a581b3d50dd5b4bd29383b462d2a5018/model). 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. ## Related documentation * [Explore traces](https://docs.orq.ai/ai-studio/observability/traces.md) * [Arize tracing setup](https://arize.com/docs/ax/integrations/platforms/claude-managed-agents/claude-managed-agents-tracing) * [Databricks unified trace table](https://docs.databricks.com/aws/en/ai-gateway/unified-trace-table) * [Datadog OpenTelemetry instrumentation](https://docs.datadoghq.com/llm_observability/instrument/otel_instrumentation/) * [OpenTelemetry delivery semantics](https://opentelemetry.io/docs/specs/otlp/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.