For the complete documentation index, see llms.txt. This page is also available as Markdown.

Unauthenticated Telemetry Events

This guide covers how to send product telemetry to Reo.dev from your own domain.

How it works

  1. Point a custom domain at the Reo.dev telemetry endpoint

  2. Send one GET request per event with your fields as query parameters

  3. You don't need to install an SDK, add an auth header, or agree on a payload format.

  4. Setting the domain up takes two CNAME records on your side:

    1. One to route the hostname

    2. One so the TLS certificate can be issued

  5. After that, requests terminate at Reo.dev, which records the event and returns immediately

  6. You'll need to register the activity_type under Product Usage configuration.

  7. Wait for 15 minutes before you start sending the events, so that system can sync.

telemetry.yourcompany.com  ->  yourcompany.telemetry.reo.dev

That request goes through the following 4 steps:

  1. Your app, CLI, or agent sends GET /data?... to your telemetry hostname

  2. telemetry.yourcompany.com resolves to yourcompany.telemetry.reo.dev via CNAME

  3. Reo.dev receives the request and returns 200 right away

  4. The event is forwarded and recorded asynchronously - after which, It goes through the enrichment flow


Send events

One GET to /data, with your fields as query parameters:

Example:


What you send

Field
Required
Notes

activity_type

Strongly recommended

  • The event name, for example cli-run or cli-import

  • This is the primary way events get grouped, so keep the list of names small and consistent

Anything else

Optional

  • Add as many key=value pairs as you want

  • All of them are stored together under the event's meta

Two things worth knowing about values:

  • They're always stored as strings, even if you send a number

  • If you repeat a key in the same URL, only the first value is kept


What Reo.dev adds

Reo.dev populates these fields as soon as the event occurs:

Field
What it is

user_id

An anonymous identifier

event_id

A unique ID for the request

ip_addr

Read directly from the request, not from a field you set, so it can't be spoofed

timestamp

Server time on arrival


What you need to do

There are 5 steps in total:

  • Steps 1-3 set up DNS and TLS for your domain

  • Step 4 registers your domain with Reo.dev, so events actually land

  • Step 5 is where you start sending events and seeing data come through

1

Choose the hostname you want to publish

  1. telemetry.yourcompany.com is the usual shape

  2. Any subdomain you control works

2

Add the routing CNAME record

  1. Reo.dev provisions an endpoint for your account

  2. They give you the exact target value to point at

3

Add the certificate validation CNAME record

  1. Reo.dev issues and installs the TLS certificate for your hostname. There's nothing to purchase, upload, or renew yourself

  2. Issuance requires domain validation, so Reo.dev gives you a second record for that

  3. Add it alongside the routing record and leave it in place. The certificate re-validates against it on every renewal

4

Ask Reo.dev to register the domain as a tenant

  1. This is the step that makes events actually land

  2. It's separate from DNS and TLS, so everything else about the integration can look correct without it

  3. Until it's done, the endpoint returns 200 for every request and silently drops every one of them

exclamation

Don't skip this step: DNS resolving and a valid certificate only mean requests can reach Reo.dev, not that they're being kept. Ask Reo.dev to register your domain before you rely on any data showing up.

5

Start sending events

  1. Pick your activity_type names before you ship

  2. They're how every event gets grouped later

  3. Renaming one after the fact doesn't relabel your history, it starts a new one alongside the old


Sending telemetry for more than one product

If your company ships more than one product, each with its own owner, you have two ways to set this up.

1

Option A: one hostname and a product field

  • Keep a single telemetry domain for the company, like telemetry.yourcompany.com

  • Add a custom field to every event to say which product it came from

  • Keep activity_type as one shared taxonomy across every product, like cli-run, cli-import, api-call

  • Let the product field do the work of separating them

What this gets you:

  • Each product owner filters to their own package value and gets a clean view of just their numbers

  • Leadership filters to nothing and sees every product at once, in one place

2

Option B: a separate hostname per product

  • Set up telemetry.product-a.com and telemetry.product-b.com as their own integrations

  • Each one follows the five setup steps above and gets registered as its own tenant

  • Worth it when products need to stay fully isolated: different teams need different access to the raw data, or a product might get spun out on its own later

Default to Option A: unless you have a specific reason to isolate the data. It's one integration instead of several, and a single dashboard beats stitching multiple ones together later.


Things to get right the first time

A 200 response doesn't mean the event was recorded:

The call is fire-and-forget by design. Reo.dev returns 200 before the event is written, not after. If you're testing the integration, check for the event in Reo.dev, not just the response code.

Nothing arrives until your domain is registered as a tenant:

DNS and TLS being correct isn't enough on its own. If events aren't showing up, this is the first thing to check.

Decide your activity_type names before you launch:

They define how your event history gets grouped. Changing a name later doesn't rename the old events, it starts tracking a new one alongside them.

Last updated

Was this helpful?