Install & operate

API reference

Ingest

No authentication; the site id is the authorisation.

The tracker posts to /api/d; /api/collect is the same endpoint under its original name, kept for existing integrations.

POST /api/d
Content-Type: application/json

{
  "site": "SITE_ID",
  "type": "pageview",          // or "event"
  "url": "/pricing?utm_source=x",
  "referrer": "https://chatgpt.com/",
  "name": "cta_click",         // required when type=event
  "props": { "plan": "pro" },
  "identity": "user-id",        // optional
  "tag": "v2"
}

Reading your data with an API key

Create a key in the dashboard under Workspace → API keys (workspace admins only). A key reads every site in its workspace and can change nothing — it is accepted only by the read endpoints, so there is no write it could reach. It is shown once; we store a hash of it.

Send it in the Authorization header. A key in the URL is refused with 401 rather than accepted, because URLs end up in logs.

# Which sites can this key read?
curl https://app.vitrus.dev/api/sites   -H "Authorization: Bearer vk_…"

# Last 30 days — every number with the query that produced it
curl "https://app.vitrus.dev/api/stats?site=SITE_ID&days=30"   -H "Authorization: Bearer vk_…"

Live data and session replays are not available to keys: live is for the dashboard, and a recording is the one thing we would rather a leaked key could never fetch.

Query endpoints

Each takes an API key or a signed-in session, and passes through site access control — another workspace's site id returns 404, not 403, so existence is not leaked. days is the window (1–365), or use from and to in epoch milliseconds.