feat(api): include visitId in the website events response

[light-merlin-dark]

What

Adds visit_id to the select in getWebsiteEvents, in both the relational and ClickHouse branches. Two lines, additive, no behaviour change to existing fields.

Why

GET /api/websites/:websiteId/events returns sessionId but not visitId, so an API consumer can group events by session and never by visit.

The column is already on the model — WebsiteEvent.visitId, indexed as [websiteId, visitId, createdAt] — and getSessionActivity already selects it in both backends. This only brings /events in line with its sibling.

The practical consequence is an N+1. Today, reconstructing visits across a date range means one /sessions/:sessionId/activity request per session, because that is the only endpoint exposing visitId. On a self-hosted 3.0.3 instance, building a 30-day dashboard view of 60 sessions:

	requests	wall
per-session activity	60	~6.5s
one paged /events read (pageSize=5000)	1	~0.66s

The single read already returns everything else needed — sessionId, createdAt, urlPath, referrerDomain, eventType. visitId is the only field missing, and without it a client either drops visit grouping or falls back to the per-session fan-out.

Worth noting for context: the per-request cost looks like a fixed application-layer floor rather than query time. The same instance answers the underlying session-activity SQL in 0.203ms (index scan), while the HTTP request takes ~110–140ms, and throughput plateaus around 9 req/s regardless of client concurrency. So fewer requests is the only lever available to a consumer.

Testing

• The modified relational query was run against a live Umami 3.0.3 Postgres instance and returns visitId correctly, with events from one session sharing a single visit id across rows.
• The ClickHouse branch mirrors the existing getSessionActivity ClickHouse query line-for-line, but I do not have a ClickHouse deployment to execute it against — flagging that honestly rather than implying coverage I don't have.

Disclosure

Prepared by Merlin (@light-merlin-dark) together with an AI agent (Claude Opus 5), from a real self-hosted deployment. Happy to adjust naming, split the backends, or add a docs note for the events endpoint if you'd prefer.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

@light-merlin-dark is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

Adds visitId to website-event API results for both supported database backends.

• Projects PostgreSQL website_event.visit_id as visitId.
• Projects ClickHouse visit_id under the same response field.

Confidence Score: 5/5

The PR appears safe to merge, with both database branches exposing the new field consistently.

The additive projections use the existing visit_id columns and established visitId alias, while the API response path accepts and serializes the additional property without an exact output schema.

Important Files Changed

Filename	Overview
src/queries/sql/events/getWebsiteEvents.ts	Adds matching visitId projections to the relational and ClickHouse queries without disrupting the existing response shape.

_{Reviews (1): Last reviewed commit: "feat(api): include visitId in the websit..." | Re-trigger Greptile}