Views

Overview of the Views API

Hand off to an LLM

Views are tabular projections over the transformations your functions produce — a saved query that turns raw extracted JSON into a filterable, paginatable, aggregatable table.

Anatomy

A view declares:

  • One or more functions to read from (by functionID or functionName).
  • A list of columns, each pinned to a valueSchemaPath (a JSON Pointer into the function's output schema).
  • Optional filters (string equality, numeric comparators, null-checks) and aggregations (count, count_distinct, sum, average, min, max).

Views are versioned: every update produces a new version, and the previous version remains immutable and addressable. Function types that produce transformations with an output schema — extract, transform, analyze, join — are all queryable through views; extract works uniformly across vision and OCR inputs.

Reading data

  • POST /v3/views/table-data — paginated rows of column values. Each row reports the underlying event's eventID (the externally-stable KSUID used everywhere else in V3) plus the projected column values.
  • POST /v3/views/aggregation-data — group-by-able aggregate values across the same query surface.

Both endpoints take a timeWindow to bound the transformation set and require at least one function to read from.

On this page