Web Analytics API: support filtering by hostname (already supported in the dashboard)

Feedback
,
1

Summary

Please add hostname (aka requestHostname) to the supported filter dimensions of the Web Analytics query API (/v1/query/web-analytics/visits/count and /visits/aggregate).

Use case

We run a multi-tenant SaaS where many customer sites (custom domains and subdomains, e.g. bookings.customer-a.com, customer-b.ourapp.app) are served by a single Vercel project. We want to report visitor counts per customer site programmatically.

The Web Analytics dashboard already supports this — there’s a “Hostnames” panel with per-hostname visitor counts, and you can click a hostname to filter every other panel by it. So the data is clearly stored and queryable per hostname.

The problem

The public API rejects hostname as a filter subject:

GET /v1/query/web-analytics/visits/count?filter=requestHostname eq 'bookings.example.com'

{
  "error": {
    "code": "bad_request",
    "message": "Invalid OData filter \"requestHostname eq 'bookings.example.com'\": Unsupported subject \"requestHostname\". Allowed: \"country\", \"deviceType\", \"environment\", \"requestPath\", \"referrerHostname\", \"osName\", \"browserName\", \"route\", \"utmSource\", \"utmMedium\", \"utmCampaign\", \"utmContent\", \"utmTerm\", \"flags\""
  }
}

Meanwhile, the dashboard’s own internal API accepts exactly this filter (from DevTools):

GET https://vercel.com/api/web-analytics/v2/stats?...&filter={"hostname":{"values":["bookings.example.com"],"operator":"eq"}}

So this looks like it only needs hostname to be whitelisted as an OData filter subject (and ideally as a by grouping dimension) in the public API — the backend already supports it.

Request

  1. Allow hostname in the filter parameter of the Web Analytics query endpoints.
  2. Ideally also allow by=hostname on the aggregate endpoints, so one call can return visitor counts for all hostnames.

Without this, per-tenant analytics via the API currently requires custom events or rewriting reported URLs via beforeSend, both of which duplicate data the platform already has. This would be valuable for any multi-tenant / multi-domain project, which is a very common setup.

2

Yeah this is would be really nice to have