Skip to main content
POST
Search
The 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.
This query requires an API key scoped to your chain in the Authorization header. Optionally include X-Session-ID for analytics and personalization; you do not need to pass chain or session in the GraphQL query itself.

Query

Parameters

All parameters are optional. Chain context comes from your Authorization header; restaurant and session context are provided via restaurantId (argument) and X-Session-ID (header).

PreferencesInput

PaginationArgs

Pagination uses opaque, base64-encoded page-number cursors:
  • Forward pagination (first / after): When after is omitted, the resolver returns the first page. When present, after is treated as the cursor for the current page and the resolver returns the next page.
  • Backward pagination (last / before): When both are present, before is treated as the cursor for the current page and the resolver returns the previous page. When only last is provided, the resolver returns the last page.
  • Cursors should be treated as opaque strings; clients should not rely on the encoding details.

Response

Match Groups

Results are grouped into three categories:

MatchStatus Enum

Match Reasons

For almostMatches and notMatches, the matchReasons array explains why:

Example

Examples

Basic Search (No Filters)

Search with Dietary Preferences

Text Search with Category Filter

Paginated Results

Full Example Response