Customers integrating third-party SaaS metric streams, such as Auth0 Metric Streams, with the Instana OTLP backend can run into a limitation where the source platform only supports a single custom HTTP header.
Instana OTLP ingestion currently requires the x-instana-key header for authentication. The documentation also states that the Instana backend requires one of the following identity attributes for entity correlation:
- host.id
- faas.id
- device.id
Alternatively, the documentation references using the x-instana-host header to provide host identity. This creates a compatibility gap for SaaS providers that only allow one header key-value pair. In those cases, the customer can provide x-instana-key, but cannot also provide x-instana-host.
This makes direct OTLP ingestion difficult or impossible for certain third-party SaaS metric stream integrations, even when the provider supports OTLP/HTTP export.
Business Impact / Customer Pain
Auth0 Metric Streams only allows a single custom header. Since Instana requires x-instana-key for authentication, there is no remaining header slot available to provide x-instana-host.
Customers are left unclear on whether:
- Instana will accept telemetry without x-instana-host if no host.id, faas.id, or device.id resource attribute is present.
- The telemetry is rejected, dropped, or accepted but not correlated.
- There is any backend-visible error that confirms why data is not appearing.
- Instana can infer or assign a default entity identity for third-party SaaS-originated telemetry.
This creates friction for customers attempting to integrate SaaS metric sources directly into Instana without deploying an intermediate OpenTelemetry Collector.
Requested Enhancement
Add support for one or more of the following:
Single-header compatible ingestion
- Allow identity metadata to be included in the same authentication mechanism, or support an alternate format where x-instana-key and source identity can be provided through one supported header.
Tenant-level default identity for SaaS metric streams
- Allow customers to configure a default host.id, device.id, faas.id, or logical SaaS source identity at the tenant/backend level for OTLP data that arrives with a valid x-instana-key but without a second identity header.
Support source/vendor identity mapping
- Provide a way to map third-party SaaS sources, such as Auth0, to a logical Instana entity without requiring the external provider to send x-instana-host.
Clear ingestion error visibility
- Provide customer-facing visibility into OTLP ingestion errors, including missing required resource attributes, missing identity headers, rejected payloads, or uncorrelated telemetry.
Documentation clarification
- Clarify whether x-instana-host is required when host.id, faas.id, or device.id are not present.
- Clarify whether telemetry is rejected or accepted-but-uncorrelated when identity metadata is missing.
- Clarify recommended integration patterns for SaaS providers that only support one custom header.
Expected Outcome
Customers should be able to send OTLP metrics from third-party SaaS providers that support only a single custom header into Instana successfully, with a documented and supported way to assign or infer entity identity.
At minimum, Instana should provide clear documentation and backend visibility explaining whether data was rejected, dropped, or ingested without correlation.
