So a variant has a SKU. I could always get a variant and have it's SKU. Now we have InventoryItem endpoint, and the SKU lives there. But it also lives as variant SKU and there is no notice of deprecation there.
A variant has/had inventory_quantity but now that lives in the InventoryLevel endpoint. The big bad warning is that these attributes are verboten now and deprecated. What does that mean? Will the variant SKU keep working even though it is an attribute of the InventoryItem?
Will a call to a variant inventory_quantity soon enough blow chunks? Why the inconsistency of moving attributes to more than one place, but keeping some and eliminating others? Should we not have a clear 1:1 movement for our codes. I am finding it hard to keep the code straight with these inconsistencies.
Please elaborate for us on where we are going with variant attributes versus new Inventory endpoints.
SKU is a weird one because in some cases it's a customer facing attribute (something you display on a channel) and also a back office attribute (something you use to manage inventory, pick, pack, ship). Currently it is available on both InventoryItem and Product Variant as you have mentioned. However, I would suggest that if you are using it as a back-office attribute, the safest way to future proof would be to consume SKU from InventoryItem.
So in other words, under the hood, when the merchant sets a SKU it is available to them in one place, but to Shopify it requires updates to two resources. Lucky Shopify.
For inventory quantity, there is no longer a way to know the quantity of a variant except to query the available level per location, and that only works if Shopify is the inventory tracker. For merchants that do not select Shopify we can no longer know inventory levels for a SKU. That will certainly earn me some pain on the phone and via email.
So moving forward, we can ALWAYS rely on SKU from both the Variant and the InventoryItem endpoints, with a nod to InventoryItem being best.
|54 seconds ago|