The Inventory Item ID is used in the new Inventory APIs. It's a separate resource from the Variant but there's a 1-1 relationship between the Variant and InventoryItem resources.
For example, if you need to update the InventoryLevel of a Variant, you'll need the Inventory Item ID as the InventoryLevel is attached to the InventoryItem. So you'll basically have to pull the inventory item ID via the Variant API (i.e. variant.inventory_item_id) first, and then make a call to the InventoryLevel API using that inventory_item_id and the location_id (new requirement when the Inventory APIs were introduced).
More info here:
Hope that helps!
If the Inventory Item ID is not specific to location (or anything else of the Varient), stange that they did not want to use the Varient ID for the new Inventory API (to update quantities). Would have made life a-whole-lot-easier for integrated developers. I'm guessing most integrated developers would have been saving the Varient ID already in their local apps. Now we have to save the Varient ID and the Inventory Item ID to perform all varient updates.
No problem Ron.
It certainly makes it more complicated as it's an additional step. It used to be possible to update the variant inventory quantity directly via the Variant API (now this field is read-only).
I believe they had to make this change when the Multi-Location Inventory feature was introduced as the database schema changed where the inventory quantity is now stored in a separate table (InventoryLevel) and must now always include a Location even if the store doesn't use the multi-location feature.
It does seem like there could've just been a direct relationship between InventoryLevel and the Variant resource instead of creating a separate InventoryItem resource, but I'm sure they had good reasons for designing it this way.
Your internal inventory item may not be the same as the final external variant product, say like an assembled product, or packs,etc.
So if I want to find the HS Code and Country of Origin for a product to quote duties on international shipping, After the Carrier Service request I've got to query the Product Variant API and then the Inventory API, making a total of three network calls, that's really convoluted, on top of that we need to query our database and an outside shipping service, making for 5 synchronous networks calls, that equals a really slow website.