A product’s dimensions and the space it occupies when packed can differ. Shopify’s 29 September developer announcement gives app teams a new way to store packed measurements, but the change starts with Admin GraphQL API version 2027-01.
The packed-product dimensions changelog describes fields for reading and writing packed length, width, height and unit. The 2027-01 reference is currently a release candidate. Use it for development testing and confirm the stable release before changing production traffic. It doesn’t mean every retailer’s current integration can use the fields today.
Start with the packing bench
Before commissioning an integration change, choose a few representative products and ask the fulfilment team to measure how each item ships. Include any protective packaging used around the item. Record the unit and who measured it, so a developer has something more reliable than a figure copied from a supplier’s product description.
Keep these measurements separate from the outer dimensions of your saved shipping packages. An item and a box are different records. A spreadsheet trial can expose inconsistent units and missing measurements before anyone writes them into an inventory system.
Use a small sample that includes a bulky item, a fragile item and a product with several variants. This is a suggested audit approach, not a claim that Shopify handles every packing constraint automatically.
Check eligibility before promising a saving
Shopify says it can select the smallest saved package that fits when every item in an eligible multi-item order has packed dimensions. It uses that package for carrier rates at checkout and when the merchant buys a shipping label. Missing measurements or no fitting saved package leave the existing selection behaviour in place.
Those conditions matter. Ask your app developer which orders are eligible in your setup and how the integration will handle incomplete records. Don’t put a projected shipping saving into a budget until a controlled test shows the result for your products and carriers.
For example, compare a basket containing two measured items with one containing an unmeasured variant. Log both results. The comparison can show where the new data helps and where your current process still applies.
Give the developer a data contract
Agree which system owns the measurements. If the warehouse spreadsheet and a product information system both write values, a later import can overwrite a careful measurement. Define who may change the record, which units the integration accepts and what happens when a field is blank.
Ask for a readback after a test write. Check the stored value. Before changing production traffic, put the tested API version and the agreed release plan into the handover so another maintainer can reproduce the check.
Our article on using Codex for Shopify development gives related context for reviewing assisted development work. Have the maintainer verify the actual API behaviour and resulting records, even when an assistant proposes the implementation.
Roll out one measured group first
Choose predictable packaging first. Compare test outcomes against the fulfilment team’s manual choice, log exceptions and correct the source data before widening the rollout.
Begin with the measurement audit. Put the planned API version, the owner of the data and the test baskets in that conversation. Reliable packing records give the later implementation a useful starting point.
Author
