What’s the most intuitive way for partners to get and update inventory for a listing?

[mikabro]

Developers,

It's Etsy's Open API/Integrations team! We want feedback on some specific topics, so we're posting questions and would love to get your opinions. We'd like to know what’s the most intuitive way for integrations to get and update inventory for a listing? Do you find the process of updating and maintaining inventory to be too involved? i.e. the amount of subsequent requests required, linking variation images, etc.

[aabrodskiy]

hey @mikabro, Great question and my main pain with the current V2 API. I've suggested some of the options in #33 to tackle this. The main idea is that the common terminology for cross-platform inventory is SKU and inventory at SKU level, therefore the entry point for getting and updating inventory is SKU. Each variant in Etsy needs to have its own SKU (that's already the best practice), and there should be an easy way to get and update the inventory by SKU, without having to make many calls or carrying risk of destroying the entire listing by submitting incorrect json for the whole of it. It's OK to have the same SKU sold in multiple listings on Etsy and we should be able to get all the offerings for the SKU and update all of them.

[foxfriends]

I find the least-intuitive part of the current system is that inventory, pricing, and SKU can all vary independently on the variation properties...

It kind of makes sense for the seller (can add little add-ons to the same SKU that don't require inventory tracking as variations that change the cost), but complicates any attempt to integrate with an external system, as those are pretty much always operating entirely on SKUs.

Some way of retrieving/updating inventory in a way that is not tied to listings and prices might help to cover both of those cases? Inventory + SKU is my first guess, but since variations can vary on inventory but not SKU as it is now, maybe it would have to be Inventory + SKU + variant options or something?

If products and inventory were stored separate from listings, and listings were created by choosing products from the list of products created previously, then you can probably still build listings with variations as it is now, but have more intuitive inventory tracking (listing + variation options = some set of products; one product could be in multiple listings, but there is only one true inventory number for that product)?

[oweiss-sqsp]

Hi @mikabro,

Thanks for the question! The “updateListingInventory” endpoint is a pain point for us as well, as it puts us at risk of unintentionally deleting / modifying unrelated data.

Our preferred approach would be a partial “updateProductOffering” endpoint that allows us to modify just the stock quantity while leaving other fields untouched. For example:

POST /v3/application/listings/{listing_id}/products/{product_id}/offerings/{product_offering_id}

{
    "quantity": 10
}

Or, a full update at the offering level would also be an improvement. For example:

PUT /v3/application/listings/{listing_id}/products/{product_id}/offerings/{product_offering_id}

{
    "quantity": 10,
    "is_enabled": true,
    "is_deleted": true,
    "price": 2.50
}

The advantages to this approach:

• It matches the existing endpoint URL patterns in the v3 API
• It allows users to directly modify the “quantity” field without accidentally modifying or deleting unrelated data
• It relies on product_offering_id as an identifier, rather than SKU. SKU is an unreliable identifier because it is:
  • Not required
  • Not required to be unique
  • Modifiable

It would be a huge improvement to inventory updates if either of the suggested endpoints was added. Please let us know if we can do anything to make that happen!