InventoryStatusType
This type is used by the ReviseInventoryStatus call to update the price and/or quantity of an item or an item variation within a single-variation or multiple-variation, fixed-price listing.
Types that use InventoryStatusType:
Call that uses InventoryStatusType:
Fields
The unique identifier of the listing being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
See the Field Index to learn which calls use ItemID.
This field is used to update the quantity of a fixed-price listing, or to update the quantity of a variation within a multiple-variation listing. To update a variation, both the ItemID and SKU fields are required to identify the listing and the specific variation within that listing, respectively.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The Quantity field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested quantity updates were successful.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The Quantity field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested quantity updates were successful.
See the Field Index to learn which calls use Quantity.
This value is the seller-defined SKU value of the item being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
See the Field Index to learn which calls use SKU.
This field is used to update the price of a fixed-price item, or to update the price of an item variation within a multiple-variation listing. To update the price of an item variation, both the ItemID and SKU fields are required to identify the listing and the specific variation within that listing, respectively.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The StartPrice field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested price updates were successful.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The StartPrice field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested price updates were successful.
See the Field Index to learn which calls use StartPrice.