Changelog

Storefront GraphQL filters on brand pages now match the brand’s products

We are beginning to roll out a fix to the product filters that storefront GraphQL returns for a brand page. You may notice changes in this area over the coming weeks.

On a store where the Brand filter is turned off in the store’s filter settings, the other filters on a brand page, such as color, size, and product attributes, used to list values and counts for the whole catalogue. The products on the page were already limited to the brand, so the filters offered options that led to no results. With the fix, those filters list only the values, and the product counts, of the products that belong to the brand.

• Values match the brand: a filter such as color lists only the values used by the brand’s products.
• Counts match the brand: the product count next to each value is calculated over the brand’s products instead of the whole catalogue.
• No change when the Brand filter is on: stores that already show the Brand filter get the same results as before.
• No change to the response: the filters keep the same fields and structure; only the values and counts they contain change.

For details, see Faceted and Textual Search with the GraphQL Storefront API.

Product image uploads now save description, sort order, and thumbnail

We’re beginning to roll out a fix so uploading a product image file with multipart/form-data saves the description, sort_order, and is_thumbnail fields sent alongside image_file.

The rollout is progressive and starts on October 8, 2026.

• Saves image metadata on file uploads: these fields were previously ignored on multipart/form-data requests and only applied when you created the image from image_url with application/json. Both request types now behave the same.
• Validates the uploaded fields: a non-numeric sort_order or an is_thumbnail value that isn’t a boolean now returns a validation error, matching the application/json request, instead of being ignored.
• Progressive rollout: the change is enabled for a growing share of stores over time, so not every store sees it on the same day. Until the change reaches a store, multipart/form-data requests behave as before: the fields are ignored and not validated. Both changes arrive together, so a store never gets saving without validation or the reverse.

For request details, see Create a product image.

Update products ignores unknown fields in image objects

The Update products endpoint no longer fails with a 500 error when an object in the inline images array contains a field that is not a writable image property.

• Unknown fields are ignored: a field such as image_url_thumbnail is skipped, and the writable fields in the same image object are applied as usual.
• Read-only fields are not saved: values sent for read-only fields, such as url_thumbnail, are ignored, as in other catalog resources.

We are beginning to roll this out. You may notice this change in the coming weeks.

For details, see the Update products reference.