When creating or editing an auth token in Settings > Auth Tokens, a new Signal type dropdown appears between the dataset restriction and permissions fields. Select a signal type to lock the token to that single type of telemetry, or leave it set to "Unrestricted" to accept all signals as before. The restriction is enforced server-side in the collector pipeline: any data that does not match the permitted signal type is silently dropped.
Why this matters for Website monitoring
Website monitoring in Dash0 is powered by the Dash0 Web SDK, which sends both spans and logs over the same OTLP connection. In backend observability, each signal type typically arrives through a separate pipeline with its own token. But the browser is different — a single Web SDK instance emits page loads, web vitals, user interactions (as spans), and console errors or custom events (as logs) through one shared auth token.
With signal type restrictions, you can now issue a dedicated token that only accepts web events. This is valuable for two reasons:
1. Security boundary. The auth token embedded in your website's JavaScript is publicly visible to anyone who opens the browser's developer
tools. A token restricted to web events cannot be abused to ingest backend traces, metrics, or profiles into your organization — even if it is
extracted from the page source.
2. Blast-radius reduction. If a web-events-only token is compromised or accidentally shared, the damage is contained to a single signal type.
Backend observability data, alerting metrics, and profiling data remain unaffected.
Interplay with other features
Signal type restrictions combine with the existing dataset restriction — a token can be scoped to both a specific dataset and a specific signal type for maximum isolation.
And, by the way, you can go and retrofit your existing authentication tokens with the new restrictions!