Skip to main content
Splendor exposes three ways to search, and they share one response shape. Whether you run a keyword query, a SQL projection, or a semantic lookup, you get back the same envelope with the same fields — so you can switch modes without rewriting how you read results.

The three modes

Keyword and full-text search with relevance ranking. Send text (or q) with the datasets to search. Scores are bm25.
Add structured where filters, a time range, and aggregations to narrow and summarize. A filter-only request (no text) browses records that match the filter.

Filtering on metadata

where clauses filter every mode. To make a field filterable, declare it under the source’s semantic.filters with a type so its values are indexed as a typed attribute:
Types are keyword, i64, f64, bool, datetime, and ip. A where clause names the field, an operator, and a value: Declare a field as array when it holds a list of values (for example tags); it is stored as a distinct multi-valued attribute, so the same path can’t be both scalar and array within a dataset. Filters declared after records were indexed apply to new records immediately; to apply one to existing records, run a filter backfill.

The response envelope

Every mode returns this shape. The fields make truncation explicit so you never have to guess whether more results exist.
Each result is normalized to a common form regardless of mode:

Readiness gates which modes work

A dataset answers text and sql queries once it is text-search ready, and semantic queries once embeddings are built. Check readiness before relying on a mode. Semantic search additionally requires the tenant’s semantic backend to be configured; when it is not, semantic requests return a clear error.
Prefer refining a query over walking pages. When has_more is true, narrowing your text, where, or time usually beats fetching cursor after cursor — and for exhaustive traversal, use an export or a view instead.