search query is where personalization happens. Pass in a guest’s dietary restrictions, allergen exclusions, and nutritional preferences—we traverse our entire ingredient hierarchy to find dishes that are safe and satisfying for them.
Results come back grouped by match quality: full matches, almost matches (with explanations), and non-matches. This gives you everything you need to build interfaces that help guests find exactly what they’re looking for—while being transparent about dishes that come close but don’t quite fit.
Chain and session context come from your headers (
X-Session-ID). You don’t need to pass them in the query.Query
Parameters
All parameters are optional. Chain and session context come from yourX-Session-ID header.
| Parameter | Type | Description |
|---|---|---|
preferences | PreferencesInput | Dietary filters (see below) |
searchTerm | String | Text search (dish name, description) |
category | String | Filter by menu category |
pagination | PaginationInput | Pagination controls |
PreferencesInput
PaginationInput
Response
Match Groups
Results are grouped into three categories:| Group | Description | Use Case |
|---|---|---|
matches | Fully meets all preferences | Display prominently |
almostMatches | Partial match with exceptions | Display with warnings |
notMatches | Does not meet critical preferences | Display greyed out or hide |
MatchStatus Enum
Match Reasons
ForalmostMatches and notMatches, the matchReasons array explains why:
Example
Examples
Basic Search (No Filters)
Example Response
Example Response
Search with Dietary Preferences
Example Response
Example Response
Text Search with Category Filter
Example Response
Example Response
Paginated Results
Full Example Response
Complete Response
Complete Response

