A Location is a place a merchant operates from: a store, a warehouse, a stockroom. Locations are operational children of a merchant, not organization hierarchy nodes.
A Location has three independently versioned parts:
- Identity (
name,metadata,status), updated withPATCH /v1/locations/{location_id}and guarded byexpected_version. - Geography (address, timezone, coordinate), published with
PATCH /v1/locations/{location_id}/geographyand guarded byexpected_geography_revision. - Inventory capability, set with the
inventoryblock when the Location is created or updated withPATCH /v1/locations/{location_id}/inventory, and guarded byexpected_inventory_revisionafter the capability exists.
Splitting them means a metadata edit and an address publication cannot invalidate each other. Send the revision you read; if it no longer matches, the write is rejected rather than silently overwriting a concurrent change.
Enabling a Location for inventory#
Creating a Location does not make it hold stock. Stock lives on inventory levels, which exist per inventory item per Location, and a Location only participates in allocation once it carries an inventory block with allocation_status: "active".
Set the block when creating the Location, or update allocation_status with PATCH /v1/locations/{location_id}/inventory. Omit expected_inventory_revision the first time you enable inventory. After the inventory block exists, send its current inventory_revision. Change stock through inventory adjustments and update item-level controls through their inventory routes. Location identity and geography writes do not replace the inventory block.
Scopes#
Location reads and ordinary writes use merchants.locations.read and merchants.locations.write. The inventory block is separately gated:
- Reading the nested
inventoryobject requirescommerce.inventory.read. Without it the object is omitted from every Location response, andinventory_allocation_statusis not an accepted filter onGET /v1/locations. - Creating or updating an inventory block requires
commerce.inventory_locations.write. This is deliberately narrower thanmerchants.locations.write, so a credential can manage whether a Location participates in inventory allocation without broader inventory authority.
Creating a Location with an inventory block in the same request requires both applicable write scopes.
Locations elsewhere on the API#
Location concepts also appear on resources that predate this surface:
location_idon devices, including filters and assignments on/v1/deviceslocation_idon inherited settings responses
Effective settings resolve through organization, then merchant, then location, then device. A device with no location_id skips the location step. Updating a device's location_id changes operational assignment, not merchant identity.
