ShipBob’s GET All Inventory Levels endpoint will return inventory quantities for each inventory_id associated with a product, which is a unique ShipBob identifier.
When creating a product via ShipBob’s product API, an inventory_id is automatically generated and returned in the product creation response. As such, ShipBob recommends implementing one of the following best practices to fetch inventory levels:
The solution would be to follow this process:
inventory_id is returned in the Product endpoint)If overselling is a large issue, you can also implement a “buffer” for certain skus, meaning that if you want to stop sales upstream at, say, 20 remaining inventory for a sku, you can send a 0 quantity to your platform of the 20 or less that ShipBob is reporting for that particular sku. This buffer will allow for a certain “reserve” stock on the ShipBob end in case there any customer service/high priority orders that need to be pushed through and fulfilled. The buffer quantity logic would need to live on your platform/integration layer, and you can decide to do this on a per-sku basis or a global setting across all skus.
The alternative solution would be for you to store the ShipBob Inventory Id somewhere on your system. This way, you can use the bulk inventory endpoint and page through all inventory records that ShipBob returns to update your system’s inventory levels. The only caveat is that if a product merge happens on ShipBob, the inventoryid could change, so you’d need a way to reconcile the inventory ids on a regular basis to ensure you store the correct id.
This would also mean that when a product is created via the API, you have the ability to store the inventory id based on the product creation response.