I’ve submitted this as a feature request on your behalf internally. The more a specific feature is requested by our merchants and partners, the more likely it is to be considered for future development by our product teams so hopefully this isn’t too far away - thanks for flagging!
Hello, @Donal-Shopify, can you tell me if any progress has been made on a query that would expose the shippingPackageID through the Admin API? If not, is there an explanation as to how to use the mutation to update the package without the id?
Hi @Novelty_IT! No update on this one yet unfortunately. The shippingPackageId is still write-only on InventoryItemMeasurementInput and there’s no corresponding field on the InventoryItemMeasurement query type to read it back. The feature request is still open internally.
To your second question about using the mutation without the ID, the shippingPackageId you’d pass to productVariantsBulkUpdate corresponds to the packages configured under Settings > Shipping and delivery > Packages in the admin.
There’s no dedicated GraphQL query to list those packages either, but the mutations for managing them (shippingPackageUpdate, shippingPackageDelete, shippingPackageMakeDefault) all accept the package ID, so you’d need to obtain it from the admin URL or track it when creating packages via the API.
I’ll update this thread if anything changes on the query side.
The issue is I cannot implement editing the shipping package in my app without this. Because we have no way to get the previous value to revert the bulk edit, plus there’s no way to show a selector to the merchant to pick the one they want to add.
Seems like a major oversight that could be solved in minutes with AI.
Thanks for the nudge, @AlexBT, and for pointing out the listing side specifically.
There’s still no public Admin API query to list a shop’s configured shipping packages, and shippingPackageId on InventoryItemMeasurementInput remains write-only, so there’s no way to read back a variant’s assigned package either.
I’ve added your feedback to the internal feature request covering both the listing query and the read path, which helps show product the demand.
In the meantime, if your app creates packages itself via the shipping package mutations, capturing and storing the returned ID at creation is the most reliable workaround albeit far from ideal for your use case.