Routing
Routing is the link between a deployed receiver and the snippet an app embeds. A superuser registers the receivers, then maps each app and environment to one of them, so every app resolves the right beacon endpoint automatically.
Once the ingest receiver is up and reachable, an app does not hard-code its address. Instead, the platform records which receiver each app routes to, and the per-app Install tab builds the snippet from that.
The problem routing solves #
A self-hosted deployment can run more than one receiver, for example one per region or one per environment. Each app needs to send beacons to the right one. Routing answers two questions:
- Which receivers exist, and what is each one's public origin.
- Which receiver an app uses, per environment.
Register an ingest service #
An ingest service represents one deployed receiver. A superuser registers it with its public origin,
the PublicBaseUrl. That origin is what the snippet derives the beacon endpoint
(/v1/events) and the collector asset URL (/v1/rum/*) from, so it must be the
externally reachable URL of the receiver (typically the ingest hostname on the edge proxy).
Add ingest routes #
An ingest route maps an app and environment to a registered ingest service.
Register the receivers
As a superuser, register each deployed receiver as an ingest service with its PublicBaseUrl.
Map apps to receivers
Add an ingest route per app and environment, pointing it at the receiver that should accept that app's beacons.
Verify the resolved endpoint
Open the app's Install tab and confirm the snippet's endpoint matches the receiver's public origin.
How an app resolves its endpoint #
With a service registered and a route in place, each app resolves its beacon endpoint from the route's target service. The per-app Install tab uses that resolved endpoint to build the embed snippet, so the snippet an operator copies already points at the correct receiver. From there the embed is identical to the hosted track in Install the snippet.