Executive summary
- What: Eight inventory_shipment webhook topics now carry an inventory_transfer_id field in their payloads, starting with Admin API version 2026-10.
- Why: Integrations no longer have to hold shipment and transfer datasets side by side and infer the relationship between them.
- Who: Teams running ERP, OMS or warehouse sync that subscribe to inventory shipment events.
What changed
Shopify added inventory_transfer_id to the payloads of inventory_shipments/create, delete, add_items, remove_items, update_item_quantities, mark_in_transit, receive_items and update_tracking. The field names the inventory_transfer record a shipment belongs to, if any. The change is purely additive: nothing is removed or renamed, and the field appears once an app moves to the 2026-10 version. A shipment created outside a transfer context has no transfer to point at, so treat the value as optional rather than guaranteed.
Why it matters
Consuming a shipment event previously meant a second trip to the Admin API, or a locally maintained map from shipment to transfer, to answer a basic question: which transfer is this movement part of? That reconciliation step is exactly where multi-location inventory sync tends to drift. An event arrives out of order, the lookup misses, a retry lands twice, and stock on hand at a location diverges from the system of record. Carrying the identifier in the payload removes a whole class of these failures, and it lowers API call volume on stores moving stock between many locations every day. For anyone maintaining ERP integration work against Shopify, this is one fewer join to own.
Role-specific impact
- Marketers: No direct impact. The indirect benefit is more trustworthy location-level availability, which is what merchandising and regional campaigns depend on.
- Developers: Move webhook subscriptions to 2026-10, add the field to payload schemas, and retire the lookup that previously resolved the parent transfer. Keep null handling in place.
- Store admins: Expect fewer discrepancies between transfer records in the admin and what downstream systems report during receiving.
Use-case example
Real-world scenario
A home goods merchant on Shopify Plus runs 11 retail locations and a central distribution centre, moving roughly 400 transfers a month. Its middleware subscribed to inventory_shipments/receive_items and then issued a follow-up query per event to find the parent transfer, adding about 1,200 extra Admin API calls monthly plus a reconciliation job that failed a handful of times each week when events landed during a transfer edit. With the transfer ID in the payload, those follow-up calls disappear and receiving events post to the ERP in a single hop.
Implementation checklist
- Confirm which inventory_shipment topics your app or middleware subscribes to.
- Move those subscriptions to Admin API version 2026-10 on a development store first.
- Add inventory_transfer_id to your payload validation and persistence layer.
- Treat a missing or null value as a shipment with no parent transfer, not as an error.
- Remove the supplementary transfer lookup once the field is confirmed in production traffic.
- Re-run your inventory reconciliation report after a full transfer cycle to confirm the counts agree.
FAQ
Q: Do we need to change anything if we stay on an older API version?
A: No. The change is additive, so existing payloads keep their current shape. You simply will not see the new field until you move to 2026-10.
Q: Will every shipment event include a transfer ID?
A: No. A shipment that was not created as part of a transfer has nothing to reference, so plan for the field to be empty in those cases rather than treating it as a fault.
Resources
Shopify webhooks documentation
Need guidance? Talk to Makro.