Executive summary
- What: Admin GraphQL API version 2027-01 adds packedDimensions to InventoryItemMeasurement for reads and to InventoryItemMeasurementInput for writes, covering packed length, width, height and unit.
- Why: when every item on an eligible multi item order has packed dimensions, Shopify can select the smallest saved package that fits and rate against it at checkout and at label purchase.
- Who: developers maintaining PIM, ERP or shipping integrations, and operations teams that own the saved package library.
What changed
The measurement object on an inventory item has been thin. On current API versions it exposes an id and a weight, which is why dimensional data has lived in metafields or external systems and never reached Shopify's own rate calculation. From 2027-01 there is a first class field: packedDimensions returns the packed length, width, height and unit, and any mutation accepting InventoryItemMeasurementInput can write the same field.
The behaviour attached to it is automatic package selection. When every item on an eligible multi item order carries packed dimensions, Shopify picks the smallest saved package the items fit into, then uses that package to calculate carrier rates at checkout and when the merchant buys a shipping label. Where dimensions are missing, or no saved package fits, existing package selection behaviour is unchanged.
Note the version gate. This is additive and scoped to 2027-01, so nothing changes on the version your app currently pins until you move.
Why it matters
Dimensional weight is a real cost line, and the gap between what a carrier charges and what was quoted at checkout is usually a packaging assumption rather than a rate error. Most stores rate against a default box, over quoting small multi item orders and under quoting bulky ones. The first suppresses conversion, the second is absorbed as margin.
What makes this useful is that the selection logic is conditional on data completeness: every item on the order needs dimensions, or Shopify falls back. That turns dimensional data quality into a shipping accuracy project with a measurable payoff, and it usually starts upstream. Packed dimensions normally originate in an ERP or PIM rather than in Shopify, which puts this squarely in ERP to Shopify integration territory.
Role-specific impact
- Marketers: shipping cost at checkout is one of the most sensitive figures on the page. More accurate rates on small multi item baskets remove friction, though only on orders where every item carries dimensions.
- Developers: plan the 2027-01 upgrade before writing against the field, and treat packed dimensions as a synced attribute rather than a manual entry. Confirm units are consistent at the point of write, and expect partial coverage to yield no behaviour change at all.
- Store admins: the saved package library becomes load bearing. Selection can only choose from packages you have defined, so an incomplete or outdated list will limit the benefit even with clean dimensional data.
Use-case example
Real-world scenario
A housewares brand with about 3,000 SKUs ships roughly 60 percent of orders as multi item and rates everything against a single medium carton. Small orders, for example two mugs, quote high enough that support regularly issues shipping credits, while genuinely bulky combinations are under quoted and absorbed. Syncing packed dimensions from the ERP into packedDimensions and curating a saved package set of six cartons lets Shopify rate against the smallest fitting box. A defensible target is a mid single digit reduction in quoted versus actual shipping variance on multi item orders, concentrated in the small basket segment where credits were issued.
Implementation checklist
- Confirm where packed dimensions are mastered today, typically an ERP or PIM, and how complete that data is by SKU.
- Plan the move to Admin GraphQL API version 2027-01, since the field does not exist on earlier versions.
- Write packed length, width, height and unit through InventoryItemMeasurementInput, with unit handling normalised at the point of write.
- Measure coverage per order profile, because selection only applies when every item on an eligible order has dimensions.
- Review and expand the saved package library so the smallest fitting option genuinely exists.
- Compare quoted rates against actual carrier charges on a sample of multi item orders before and after.
- Keep the fallback in mind when modelling: missing dimensions mean existing behaviour, not an error.
FAQ
Q: What happens when only some items on an order have packed dimensions?
A: Automatic package selection does not apply. Shopify keeps its existing package selection behaviour, so partial data delivers no benefit. Coverage per order profile matters more than overall SKU coverage.
Q: Can we use this on our current API version?
A: No. packedDimensions starts at Admin GraphQL API version 2027-01. On current versions the measurement object exposes only id and weight, so plan the version upgrade as part of the work.
Resources
InventoryItemMeasurement API reference
Need guidance? Talk to Makro.