Safely Update Product Inventory
Read before writing and verify afterward. An expected quantity is not an equally strong lock on every platform.
Prerequisites
First complete a read-only connection check. A provider write needs a paid write entitlement, write permission, the selected store in scope and its specific capability. Review exact store, item and proposed values. Ordinary writes do not each require Store MCP browser approval.
Steps
- Read inventory.get for the selected listing and every relevant page. Record the returned inventoryId, current quantity, variation and location.
- Check the row’s supported writes. Choose inventory.set for an absolute count; inventory.adjust is Shopify-only and is not generally available through public onboarding.
- Review the intended count and last observed expectedQuantity. Send one inventory.set with a new idempotencyKey.
- Read inventory again. If a conflict occurs, refresh and re-evaluate the merchant’s intent. If the outcome is unknown, inspect operations.get and provider state first.
Safe example
The example uses synthetic names. Select your own authorized store and verify every identifier before a write.
For the selected synthetic DEMO-MUG inventory row, read the current quantity and identify its location. Propose setting it to 8, showing the observed quantity. Wait for review before writing.You’re done when…
Expect the selected row to show the intended count after the write. Check the same location in the provider dashboard and inspect Activity; do not infer success from a request being sent.
Limitations
Shopify uses compare-and-swap. eBay and WooCommerce use a read/check followed by an update, so concurrent dashboard edits can race. Square physical counts use provider idempotency but are not a Shopify-style compare-and-swap. There is no atomic multi-store stock update.