attributes parameter to specify which product fields to include in the response. This lets you optimize response payload size by requesting only the data you need.
Only attributes marked as visible on storefront can be requested in the
attributes parameter or used in filters. Attributes marked as not visible, such as internal computed fields, will be rejected if included in API requests. See Visible in API responses for more details.Core product attributes
The following attributes are available for all products and can be requested in theattributes[] parameter:
Special attributes
Example API request
Example response with selected attributes
By default, if no
attributes parameter is provided, all available attributes are included in the response. Specifying attributes helps reduce response payload size and improve performance.Selecting nested fields
In addition to top-level attributes, theattributes parameter accepts dot-notation paths that let you trim nested objects, slice arrays, and filter collections to just the entries you need. This keeps responses small for storefront tiles and product detail views without making a separate request per shape.
Selectors are scoped to the response shape — they do not change which products are returned. Use filters to control the product set; use field selection to control the payload per product.
Field selection is a no-op for plain dotted paths (for example,
variants.price) — backward compatible with existing integrations. Modifiers ([], [n], [start:end], [key=value]) opt you into the trimming behavior described below.Selector forms
Multiple selectors that target the same collection are merged. For example,
variants[].id plus variants[].price returns variants trimmed to {id, price}.
Slicing and indexing
[start:end]returns the half-open slice, using zero-based positions.[n]returns the single entry at that position, still wrapped in the array.[:n]and[n:]are shorthand for “firstn” and “fromnonward”.- Negative indexes are not supported.
variants use the storefront-visible position order. Hidden variants (for example, B2B-only variants when the request is not B2B) are excluded before the slice is applied.
Equality filters
[field=value] keeps only the entries whose field equals value. Values can be unquoted, single-quoted, or double-quoted — quote them when the value contains spaces or punctuation. Numeric values compare numerically, so price=110 matches a stored 110.00.
- For arrays like
variantsandimages, filtering trims the array in place. The parent product is still returned even if no entries match. - For map-shaped fields like product
metafields({namespace: {key: value}}) and variantinventory_levels({location_id: quantity}), filtering trims the map while preserving its shape. - Filtering on a field that doesn’t exist on the entries (or on a hidden internal column) is a no-op rather than an error, so the response shape stays consistent.
>, <, >=, <=, !=), boolean combinators (AND/OR, &&/||), and IN lists are rejected at validation time.
first_or_matched_variant and field selection
Trimming or filtering variants does not affect first_or_matched_variant. The matched variant is still derived from the full variant set, so a request like variants[sku=NOPE] combined with first_or_matched_variant returns an empty variants array alongside the regular matched variant.
Validation and errors
Each collection may carry only one array modifier across all selectors in a single request. Mixing two modifiers on the same collection (for example,variants[:2] and variants[sku=ABC] in the same request) returns a 400 with a structured body:
Examples
Return product tiles with the first two images, only the matched variant’s price, and metafields from thecustom namespace:
Field selection respects API visibility. Attributes hidden from storefront responses are rejected the same way they would be in a plain
attributes request — selectors can never re-expose a hidden field.