The Querix search platform
The customer-visible behavior behind exact catalog filtering, natural-language discovery, secure pagination, and fresh results.
01
What Querix does
Querix handles both explicit catalogue search, such as a product with a location, price, and duration constraint, and need-based search where the customer cannot name the right product. The API chooses the appropriate search path while preserving tenant rules and returning the current approved catalog fields.
Structured browse
Fast filters and stable pagination for broad catalogue queries.
Semantic discovery
Intent-aware retrieval for functional language, vocabulary gaps, and ambiguity.
Tenant-safe by design
Per-tenant credentials, limits, response fields, state, and storage.
02
How requests are handled
- 01
Authenticate the tenant endpoint
- 02
Interpret explicit filters and intent
- 03
Choose browse or semantic retrieval
- 04
Hydrate current approved catalog rows
- 05
Return results, diagnostics, and a next cursor
03
When each search path is selected
| Field or role | Type or store | Contract |
|---|---|---|
| bike | Catalog browse | Uses indexed category values and catalog-safe pagination for broad discovery. |
| bike in Chennai under 1000 | Exact filter | Enforces the explicit category, location, and price constraints. |
| red bike with ABS | Intent-aware search | Combines exact constraints with descriptive meaning before ranking current rows. |
| equipment for a distant event | Need-based discovery | Uses inferred categories as ranking hints so useful alternatives remain possible. |
| Repeated normalized request | Cached search session | Reuses the ranking session while still fetching current approved catalog rows. |
04
Freshness and tenant boundaries
Search indexes select and order candidate IDs; the tenant's canonical database supplies the current public fields before a response is returned. This keeps display data fresh while search state, credentials, limits, and pagination remain isolated per tenant.
- Public response fields are allowlisted for each tenant.
- Explicit filters are enforced; inferred intent remains a ranking hint.
- Query sessions and cursors cannot be reused across tenant endpoints.
- Catalog changes that affect retrieval are refreshed through the validated data lifecycle.
05
What your team integrates
Your integration needs a provisioned tenant slug, a server-side API key, one backend proxy route, and a small client state model for the active query and next cursor. Querix operates the search and index lifecycle behind that contract.
| Field or role | Type or store | Contract |
|---|---|---|
| Tenant endpoint | HTTPS API | A company-scoped route protected by an issued API key. |
| Backend proxy | Your application | Keeps the tenant key server-side and forwards validated search requests. |
| Search session | Query + cursor | Starts with a query and advances with an opaque, short-lived cursor. |
| Health checks | Readiness + tenant health | Separates public readiness from authenticated tenant dependency status. |
Credential boundary
The tenant API key stays in your server-side secret store. Browser and mobile clients receive mapped search results, never the permanent credential.