What It Does
Use the Square Inventory API to adjust inventory quantities and review inventory changes for products in a Square catalog.
A Square seller maintains inventory to keep track of the quantity of products for sale or services for hire. Inventory tracking is essentially the process of moving quantities of item variations between the different inventory states. For example, when the online order for a leather collar and heavy sweater is processed, the on-hand quantities for leather collar and heavy sweater are automatically updated by moving the number of purchased units for each item variation from
In addition to automatic inventory tracking, Square supports nuanced inventory tracking (such as receiving stock and marking waste) and reconciliation.
With inventory, the seller can get answers to questions like "How much do I have in store now?" and "How many of a particular item were lost?" Through historical data, the seller might even get a view of trends of how fast a particular product sells or how soon a product should be restocked.
For products or services to be tracked in an inventory, they must be defined as item variations in the Square catalog. In other words, a catalog defines what the seller has for sale, whereas an inventory describes how much the seller has in stock or has changed in stock. In the Seller Dashboard, managing the catalog and maintaining the inventory are integrated in the Item Library.
The Square Inventory API lets you create applications to manage Square inventories programmatically on behalf of Square sellers. Specifically, you can use the Inventory API to adjust inventory quantities and review inventory changes for products in a Square catalog. To track new products or services, you must enable your application to call the Square Catalog API to create appropriate items with required item variations.
The Inventory API is only available for applications using
Square-Version2018-09-18 or later. For more information, see Versioning in Square APIs.
The Inventory API does not support the tracking of subcomponents, ingredients, or product bundling.
Anonymous Inventory API calls are not allowed. All Inventory API calls must include an authorization token for the targeted Square account.
All applications using OAuth to read inventory information must have
INVENTORY_READpermission for the targeted Square account.
Applications using OAuth to modify inventory quantities must have
INVENTORY_WRITEpermission for the targeted Square account.
The Inventory API exposes a set of objects to represent inventory adjustments and physical counts for quantities of products (as item variations) and transitions of stocked products to the relevant inventory state. These include the following key data types for the Inventory API:
InventoryCount. It defines the computed quantity of an item variation at a specific location with a specific inventory state.
InventoryAdjustment. It describes the quantity of an item variation transitioning from one inventory state to another.
InventoryPhysicalCount. It defines the verified quantity of an item variation at a specific location with a specific state as determined by a manual count or trusted system.
InventoryTransfer. It defines the quantity of an item variation transitioning from one location to another. Inventory transfer between locations is currently read-only information to the API. It is limited to the Seller Dashboard for items available for retail subscribers.
SourceApplication. It describes the application that makes an inventory change and helps trace sources of inventory changes.
InventoryPhysicalCount objects are similar in that they both describe the current quantity of a
InventoryPhysicalCount is a provided value and
InventoryCount is a computed value.
InventoryPhysicalCount represents the quantity of an item variation that is physically present. For example, a physical count might come from an employee counting the item variations on hand or from syncing with an external system.
InventoryCount represents the quantity that Square thinks is present based on the known sequence of inventory adjustments since the last physical count update. In an ideal world, the values of
InventoryPhysicalCount are identical. But in most cases, item loss, accidental damage, and human error create discrepancies between
As a specific example, consider the case where a seller receives a quantity of dog collars into inventory, sells some, accidentally damages some, and then recounts them at the end of the day to reconcile the inventory. Initially, there are no collars in stock. Before opening the store in the morning, the seller receives 100 small leather collars from a vendor and adds them to the inventory by transitioning 100 units from NONE to IN_STOCK to make them available for sale. During the course of the day:
The seller sells three collars to a customer in the store using Square Point of Sale, which automatically moves three units from
An online customer buys one collar on the store website (built with Square APIs), which moves one unit from
An accident in the store damages two collars so the seller manually transitions two units from
WASTEbecause they are no longer available for sale.
At this point, the calculated inventory count for small leather collars in the
IN_STOCK state is 100 − 3 − 1 − 2 = 94 units.
At the end of the day, the seller counts all the small leather collars in the store and finds that there are only 93 collars available for sale. To reconcile the computed and verified counts, the seller pushes the physical count to Square, which updates the
IN_STOCK quantity of small leather collars to 93.
The main point to understand is that inventory adjustments are handled by moving quantities of item variations at a given location from one state to another rather than assigning and decrementing a single quantity.