Use Case & Current Limitation: We rely on the Vercel Web Analytics API to pull aggregated metrics across our application—specifically focusing on the pages dimension (requestPath).

Currently, the aggregate endpoint caps returned rows at the top 100 results, grouping all remaining entries under an unsegmented Other category.

Previous Workaround & Breakdown: Previously, we worked around the 100-row cap by segmenting queries via OData $filter expressions, retrieving chunks and explicitly filtering out already-seen paths in subsequent calls. However, as the number of paths grows, this approach breaks down:

Query strings quickly hit standard HTTP request and URL character length limits.

Crafting complex exclusion filters (not (requestPath eq '...' or ...)) creates fragile, heavy queries prone to failure.

Using startswith prefix chunking is difficult to maintain reliably for dynamic routes or sites with deep, non-uniform URL hierarchies.

Proposed Solution / Feature Request: To make the Analytics API viable for sites with hundreds or thousands of unique pages, we would like to request one of the following:

Native Pagination Support: Add standard offset-based pagination ($skip alongside $top) or cursor-based pagination to the aggregate endpoint so developers can reliably page through results past the first 100 rows.

Configurable / Higher Result Limits: Allow setting a higher limit parameter (e.g., up to 500 or 1,000 items) when querying dimensions like pages.

POST-based Query Endpoint: Alternatively, provide a POST query endpoint accepting a JSON body to define complex OData filters without running into URL/header length caps.

Having native pagination or expanded limits would allow teams to build reliable data pipelines and sync analytics data to internal reporting dashboards without running into artificial data cutoffs.