Browse with filters and counts
This is the storefront from the top of the lesson. Every control on it — the rails, the counts, the price range, the sort — is the search you built, dressed as a shop.
Filters that count
The storefront starts empty — results are earned by a search or a filter, the way a real store's search page works. Tick Apparel and the 8 apparel products appear — and every option on every rail shows how many results it would leave. That's the difference between a filter and a dead end: a shopper never clicks into an empty page, because "Pulsar (2)" told them what to expect before they clicked:
Suggest as they type, search when they mean it
The search box uses both APIs, each where it belongs. As the shopper types, the dropdown under the box is the suggest endpoint — "ve" prefix-matches every Vello product by name, with the current filters still applied. The grid doesn't move until they actually search: pressing Search, hitting Enter, or picking a suggestion runs the search endpoint with that query.
What your page asks for
The grid is a filtered search — the shopper's query and ticks become the query and
filter, their sort choice becomes the ordering, and the counts come from the facets. As the
filters change, the storefront just re-runs the same requests from the last step:
GET https://api.searchstack.dev/search/Demo/products/1?query=&filter=category eq 'Apparel' and in_stock eq true
X-API-Key: {your key}
A read-only key is safe to use straight from the browser, so a static shop page can do everything the finished example does — there's no server of yours in the loop.
Go deeper: Searching — filters, sorting, paging and counts in the reference.