TotalSupplyQuantity Inventory.ListInventorySupply return bad data


Anybody experiencing TotalSupplyQuantity from Inventory.ListInventorySupply API returns bad data? It shows that my listing still has 50, even though when I log into SellerCentral, there’s only 1 available, 1 reserved, 0 inbound. So it is a total of 2 total. This is causing issues for me to making proper decision on inventory replenish and price setting.

Is the TotalSupplyQuantity returned from API is actually stale data? I’d expect Report could be a day or more older, but API call should return real time data, and I don’t see document mentions whether this quantity is real time or not.



I have the same problem, the data is garbage.


Same problem. Any updates on this?


I got an detailed explanation as follows, which I understand as don’t expect Inventory.ListInventorySupply to match with the fullible quantity displayed in SellerCentral. In a later reply, I was advised to use two reports, GET_AFN_INVENTORY_DATA and GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA, instead. But I have not really been able to look into much details.

basically Fulfillment Inventory -> ListInventorySupply numbers do not match up with FBA Inventory reports. We recommend sellers and developers use the reports instead. For a more detailed reason to why:

There has been some confusion between the Fulfillable/Reserve quantities shown in Knights/MYI and the Instock/Total quantities returned from MWS ListInventorySupply API. These values are both calculated from GPI Supply/Demand/Bound data. However, these values are calculated differently and can not be mapped directly without looking at raw Supply/Demand/Bound quantities. Fulfillable and Reserve quantities are calculated based on Supply, Demand and Bound data. Calculation Rules:

Only include Supply with Confidence > 0
Do not include Unassigned Demand
Bound is only counted for units with Condition == Sellable
Fulfillable = (Sum of all Supply) - (Sum of all Supply with Category DcXfer) - (Sum of all Demand)

If (Sum of all Supply) - (Sum of all Supply with Category DcXfer) - (Sum of all Demand) < 0, set Fulfillable = 0. We can not have negative Fulfillable quantity. We simply subtract out sum of Supply/Demand quantities, not concerned with matching Demand to Supply in a given FC or available at a given date. Instead of simply subtracting the Sum of all Demand Quantities from the Sum of all Supply Quantities, we match Demand to a specific Supply.
Matching Rules In order of Precedence:

Match Assigned Demand before matching Unassigned Demand
Match Demand to Supply at same Warehouse
Match Demand to Supply with Highest Confidence
Match Supply to Supply with soonest AvailableDate

We first match Assigned Demand to Supply at the same FC with highest confidence and Supply AvailableDate before Demand NeedByDate. If Demand was not able to be matched to Supply at same FC with correct date, we then will look to match with remaining Supply at any FC with highest confidence and soonest AvailableDate. Next, we match Unassigned Demand to Supply with Highest Confidence and soonest AvailableDate (cant match by Warehouse since Unassigned Demand does not have an attached Warehouse). If there is more Demand than Supply, all Supplies will have quantity of 0. After all Demand has be matched and subtracted from Supply, we consider Sum of all Supply as part of Total Quantity. This includes additional Supply with Categories ARRIVING, PO, VENDOR and DCXFER that were not considered part of Instock Quantity.

Fulfillable/Reserve and calculated very differently from Instock/Total quantities so it is difficult to relate the two quantities quickly.

Key difference to be aware of in the 2 sets of Quantities:

Bound is included in Reserve, but not included anywhere in Instock/Total
Unassigned Demand is included in Instock/Total calculations, but not in Fulfillable/Reserve
Supply with Confidence == 0 is excluded from Fulfillable/Reserve calculations, but all Supply is included in Instock/Total calculations.
Demand is matched to specific Supply when calculating Instock/Total.

This will cover pretty much the situation with the operation in question, and why we advise for these circumstances to use the reports method instead of the current API operation you’re attempting to utilize at the moment.