Find products in a Wix store using the Catalog V3 Search Products and Query Products APIs.
Use Search Products for text search and name-based lookup. Use Query Products for structured filtering, sorting, paging, and listing products.
| Need | Endpoint | Notes |
|---|---|---|
| Find products by name or free text | Search Products | Best for user-provided names, keywords, and broad product lookup. |
| List all products or page through the catalog | Query Products | Supports paging and structured filters on the fields listed below. |
Filter by id, slug, handle, dates, or visible | Query Products | Best for exact structured criteria. |
| Filter by price — "products under $20", "between $10 and $50" | Search Products | Query Products has no price filter, so filter server-side here (STEP 1) instead of paging the catalog and comparing amounts yourself. |
| Need exact name matching after text lookup | Search Products + client-side match | Search by the name text, then match the returned product.name in your own code. |
Use Search Products when the user gives a product name, keyword, or other text expression, and for price criteria, which Query Products cannot filter on. Free text goes in search.search; price and other structured criteria go in search.filter. Send only the part you need:
The response puts the matches in products:
Query Products returns the same envelope.
For exact name matching, search with the user-provided text and then compare the returned product.name values in your own code.
Use the POST Query Products endpoint to query products. The endpoint returns up to 100 products per request.
Endpoint: POST https://www.wixapis.com/stores/v3/products/query
Basic query (all products, default fields):
This returns all products with their default fields, including inventory for product-level availability.
Take availability from inventory, and look up any other field you need in the Catalog V3 docs rather than carrying a name over from Catalog V1 — the two catalogs do not share a product shape. A name that isn't on the V3 product reads as undefined rather than raising, so the request still succeeds and a check against it quietly matches nothing: an availability question answered that way returns an empty list, which reads as "everything is in stock" instead of as a failure.
fields parameterThe fields array requests additional fields beyond the defaults. It does NOT accept property names like "name" or "id".
⚠️ CRITICAL: Valid fields enum values:
| Enum Value | Description |
|---|---|
URL | Product page URL |
CURRENCY | Currency information |
INFO_SECTION | Info sections (rich content) |
MERCHANT_DATA | Merchant-specific data |
PLAIN_DESCRIPTION | Plain text description |
INFO_SECTION_PLAIN_DESCRIPTION | Info section plain text |
SUBSCRIPTION_PRICES_INFO | Subscription pricing |
BREADCRUMBS_INFO | Category breadcrumbs |
WEIGHT_MEASUREMENT_UNIT_INFO | Weight unit info |
VARIANT_OPTION_CHOICE_NAMES | Variant option choice names |
MEDIA_ITEMS_INFO | Additional media items |
DESCRIPTION | Rich text description |
DIRECT_CATEGORIES_INFO | Direct category info |
ALL_CATEGORIES_INFO | All category info |
MIN_PRICE_VARIANT | Lowest-priced visible variant |
INFO_SECTION_DESCRIPTION | Info section rich content |
THUMBNAIL | Thumbnail image |
DIRECT_CATEGORY_IDS | Direct category IDs |
PRODUCT_CHOICES_MEDIA_REFERENCES | Choice-specific media |
WRONG – these are NOT valid field values:
CORRECT – use enum constants or leave empty for defaults:
CORRECT – requesting additional fields:
QueryProducts supports filters only on these fields. Price is not among them, so answer a price question with Search Products rather than paging the whole catalog and comparing amounts in your own code:
| Field | Supported Filters | Sortable |
|---|---|---|
id | $eq, $ne, $exists, $in, $startsWith | No |
handle | $eq, $ne, $exists, $in, $startsWith | No |
options.id | $isEmpty, $hasAll, $hasSome | No |
slug | $eq, $ne, $exists, $in, $startsWith | Yes |
createdDate | $eq, $ne, $exists, $in, $lt, $lte, $gt, $gte | Yes |
updatedDate | $eq, $ne, $exists, $in, $lt, $lte, $gt, $gte | Yes |
visible | $eq, $ne, $exists, $in | Yes |
Query with filter and sort:
Filter by product IDs:
When there are more products than the page limit, use cursor-based or offset-based paging:
Check the response pagingMetadata to determine if more pages exist.
SCOPE.STORES.PRODUCT_READ_ADMIN permission.id, name, slug, visible, productType, inventory, media, createdDate, updatedDate.pagingMetadata reports no more results — and select on each returned product's inventory availability status in your own code, rather than putting it in query.filter.fields parameter adds fields on top of the defaults — you never need to request id or name explicitly.To find products by name or free text, use POST https://www.wixapis.com/stores/v3/products/search. To list, page, sort, or structurally filter products, use POST https://www.wixapis.com/stores/v3/products/query. Use fields: [] for defaults, or pass valid enum values like DESCRIPTION, URL, ALL_CATEGORIES_INFO for additional data. Never pass property names as field values.
Last updated: 16 August 2026