now the ‘image’ field is deprecated in API version 2026-10 for product variants, we really miss some ‘featuredMedia’ new field. This may sound absurd, as we can gather all media elements through the ‘media’ connection. But this implies a really big change when using it in bulk operations.
So far, we could use the deprecated field image, which was included in the variant lines in the jsonl response. However, if we migrate to the ‘media’ connection (as recommended in the doc), the media elements will come in new lines in the jsonl. If we just wont the featured media, as used to be intended when using ‘image’, the complexity grows considerably.
Please could you consider to add some ‘featuredMedia’ field for variants? It already exists for products, it would be exactly the same idea.
I’m happy to help submit some feedback on this change on your behalf internally.
Just to confirm I understand your issue here correctly, you’re concern is specifically with Bulk Operation Queries requesting media on product variants, and returning the media in a separate line item on the JSONL file, due to productVariant.media being a connector, rather than an individual field directly on the productVariant object?
the problem is that, according to the doc, the deprecated field ‘image’ can be replaced by ‘media’. However, this is not a direct change, because ‘image’ is a field and ‘media’ is a connector. This already have a big impact, but this impact makes the complexity grow a lot especially in the bulk operations case.
In the case of products, this is solved with the ‘featuredMedia’ field. I am just asking if having this ‘featureMedia’ also in variants is possible.
I appreciated the added context, I will absolutely be sharing this feedback with our developers internally. While we can’t guarantee that a featuredMedia field on product variants will be added, I can assure you that our developers and product managers do take all our merchant and partner feedback with great value when determining future features and platform changes, and the more feedback we get like this, the more likely a change would be made.
I’ll second this as a problem. Complexities of having to deal with additional line types in the JSONL aside, bulk queries being limited to 5 connections means we have to pick and choose what we need, and if we’re already capped at our 5 on a query now we either need to drop something that might be critical to operations, or implement even more complex workflows to try to join multiple bulk query results/iterative ad-hoc queries together.