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, each with its own revision and its own write route:
- Identity (
name,metadata,status), updated withPATCH /v1/locations/{location_id}and guarded byexpected_location_revision. - Geography (address, timezone, coordinate), published with
PUT /v1/locations/{location_id}/geographyand guarded byexpected_geography_revision. - Inventory capability, replaced with
PUT /v1/locations/{location_id}/inventoryand guarded byexpected_inventory_revision.
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".
Send expected_inventory_revision: null to create the block, or the current revision to replace it. The block is bounded on purpose: this route cannot change Location lifecycle or geography.
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. - Writing the inventory block requires
commerce.inventory_locations.write. This is deliberately narrower thanmerchants.locations.write, so an operations credential can fence a Location for inventory without gaining authority over Location lifecycle.
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- Location-scoped settings policies through
/v1/settings/policies
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.
