Tenancy and ingestion
One ingestion path for every source, with tenant identity resolved from the API key at the edge — stamped server-side and impossible to spoof from the client.
Everything you send to Radicas travels one path and gets its tenant identity the same way: from the API key on the connection, never from the payload. This page explains how, and why it cannot be spoofed.
One ingestion path
Whether telemetry comes from the Radicas SDK, a raw OpenTelemetry exporter, or your own Collector, it arrives at the same standard OTLP endpoint. There is no per-source pipeline: every new source normalizes into the same tables. That uniformity is what keeps cost attribution consistent across frameworks and languages.
How a span gets its tenant
The ingest gateway authenticates each connection and stamps tenant identity server-side:
- Your exporter sends OTLP with
Authorization: Bearerand your ingest key. - The gateway hashes the key and resolves the owning tenant from the key registry — entirely server-side.
- Any client-supplied tenant header or attribute is not trusted: the gateway strips tenant headers from the request.
- A trusted internal tenant header is set for the pipeline behind the gateway.
- The collector stamps
radicas.tenant_idonto every span, metric, and log with an upsert — meaning a client-suppliedradicas.tenant_idvalue is overwritten, not merged.
The result: radicas.tenant_id in stored data always reflects the key that authenticated the connection, and nothing else.
Why an intermediary cannot spoof
The gateway authenticates the key of the connection to Radicas, not anything inside the payload. A Collector sitting between your agents and Radicas can batch, retry, redact, or add attributes — but whatever it writes into resource attributes, the upsert stamp overwrites the tenant value at the edge. Tenant identity derives only from the validated key, so an intermediary (or a misconfigured client) cannot write into another tenant, accidentally or otherwise. Per-tenant rate limiting is enforced at the gateway on the same basis.
One key, one tenant
Each ingest key belongs to exactly one tenant, and everything sent with it lands in that tenant. To forward telemetry for multiple Radicas tenants through a single Collector, configure one exporter per key; native multi-tenant fan-out through one pipeline is planned post-MVP. Key issuance, reveal, rotation, and revocation are covered in API keys.
Estimated vs authoritative cost
Two standards, one engine — real-time estimated cost from telemetry, authoritative cost from invoices, reconciled span by span, and the allocated basis that never reconciles.
Features, users, and allocation
How radicas.feature and user context drive per-feature profitability, and how rate cards and share-of-seat allocation make seat spend attributable.