Lists
A list is the unit of search. It is a collection of records that all share the same fields and one public web address. An online shop keeps its catalogue in a products list; a directory keeps its people in a people list; a cinema keeps its titles in a movies list. Give the platform a list and it gives you back a working search API for it — nothing to host, nothing to deploy.
Auto-plays · use Back / Next to step through at your own pace.
Create a list
- Go to Lists and click Create List.
- Give it a name (letters, numbers and single hyphens) and pick a subscription — that decides which search service hosts it.
- Optionally choose an embedding model to switch on meaning-based (semantic) search. Leave it as None for plain keyword search; you can add one later.
- Click Create. The list is live immediately, with its own public search endpoints.
Add records and shape the schema
Inside a list you add records (with Add Search Result, a bulk import, or the API) and shape what search can do with them from the Fields menu. Every list starts with a searchable name; add fields for anything else you want to search, filter or return. The search box at the top of the list lets you try queries against your own data as you go.
Every list is a public API
Each list exposes its own set of public web addresses, so a front-end can call it directly:
| Endpoint | What it does |
|---|---|
suggest | Lightweight as-you-type completions for an autocomplete box. |
search | Full search returning whole records, with filters, paging and geo radius — the full request is on the Searching page. |
facet | Value counts for a single facet field — the data behind a filter sidebar. |
related | Records most similar to a given one (see below). |
The base is https://api.searchstack.dev/; a read-only key is safe to ship in a browser. Full request shapes live on the Searching page — this page is about the feature, not the wire format.
Related results — “more like this”
The related endpoint returns the records most similar to one you name — the seed. There is no query to type: the seed record itself is the query. Similarity is computed from vector embeddings, so results are related by meaning, not shared keywords. It is the building block behind “customers also viewed”, “more like this” and “similar articles” rails — one request per detail page, no recommendation engine to run.
Fetching the records related to The Matrix in a movies list returns other science-fiction titles with similar plots — even when their names and casts share no words with the seed. It needs the list to have an embedding model attached (that is what produces the vectors). To find records similar to an external image instead of an indexed record, use Image Search.
Lifecycle
A list can be transferred between search servers without its public address ever changing. Breaking schema changes (renaming or removing a field) create a new version automatically, while additive changes do not, so deployed clients never break. Other accounts can be given write access as contributors, and several lists can be searched together as one via groups.
A worked example
Say you are building a film site. You create a movies list, make plot and name searchable, add year as a facet and image_url as a resource, then import your catalogue. Straight away you have a search box (search), an autocomplete (suggest), a “by decade” sidebar (facet) and a “more like this” rail on each film’s page (related) — four features, one list, and not a line of search infrastructure to maintain.