Filters
Publish safe request-time filters with type-compatible, per-field operator allowlists.
Filters narrow analytics results. ReportPlane separates filters built into a definition from filters a runtime caller is allowed to provide.
Allowed filters
An allowed filter names a field and optionally a per-field operator list. The public caller cannot filter an arbitrary model field just because it exists.
If the operator list is omitted, the runtime still limits the field to globally valid and type-compatible operators.
Operators
| Operator | Value shape | Compatible use |
|---|---|---|
equals | Scalar | Exact match |
not_equals | Scalar | Exact non-match |
contains | Scalar | Text or array contains value |
not_contains | Scalar | Text or array does not contain value |
in | Non-empty array | Scalar is one of the values |
not_in | Non-empty array | Scalar is not one of the values |
between | { "from": ..., "to": ... } | Numeric or time range |
gt, gte, lt, lte | Scalar | Numeric or time comparison |
exists | No value required | Field presence |
contains_any | Non-empty array | Array has at least one value |
contains_all | Non-empty array | Array has every value |
Numeric and timestamp fields support exact, set, range, and comparison operators. Booleans support exact and set operators. Strings support exact, contains, and set operators. Arrays use array contains operators. Root object and json values are not directly filterable; use an explicit supported dotted field path.
Runtime example
{
"field": "occurred_at",
"operator": "between",
"value": {
"from": "2026-08-01T00:00:00Z",
"to": "2026-08-02T00:00:00Z"
}
}
Repeated filters
Repeated equals filters for the same field are combined into an in condition. Repeated not_equals filters become not_in. This preserves the intended set behavior without building contradictory equality clauses.
Fixed and access filters
Definitions can carry fixed filters, and query clients can carry access filters. These are policy constraints rather than caller-controlled convenience filters. A public request cannot remove them.
In the console, Analytics create and edit screens expose definition-level fixed filters as Required Filters. The Analytics detail page shows the same rules under Definition → Required Filters, alongside the raw canonical definition. Changing or removing one changes every execution of that Analytics API.
Rolling time policy
A fixed or access filter can express a timestamp relative to the start of each query execution. Core resolves it once to an absolute UTC timestamp before planning, so the same definition works across BigQuery, ClickHouse, Snowflake, Elasticsearch, and OpenSearch.
{
"field": "observed_at",
"operator": "gte",
"value": { "relative_time": "-24h" }
}
The offset uses Go duration syntax such as -30m, -24h, or -168h. Relative values are policy-owned: runtime callers cannot remove or widen a fixed rolling window. Normal Analytics cache TTL still applies after the boundary is resolved.
contains is a substring match, not a prefix-only match. For example, a required url contains /blog rule also matches a value where /blog occurs later in the URL.