open-api
open-api copied to clipboard
[FEATURE] Update product stock levels directly with the SKU parameter
Is your feature request related to a problem? Please describe. When syncing warehouse stock levels from our warehouse database to Esty listings we have to fetch all products in our Esty shop then look through all of them to find the the product with the corresponding SKU to update the stock levels for. Also you must over write the whole listing which is prone to errors.
Describe the solution you'd like API endpoint that takes SKU as a parameter key and allows the stock count to be added as the key value
Describe alternatives you've considered Fetching all listings from Esty then finding corresponding SKU to update the stock levels for. Finally overwriting the whole listing to update the stock level.
I am new to the Etsy API (using V3) but I have been developing for the web for the last 20+ years and I can honestly say this is one of the biggest design failures in the API. SKUs are the seller's reference and, in theory, likely to be their, unique code and quite possibly the primary key in their DB.
A public-facing API should allow the consumer of the API to undertake operations on the system in the most efficient way possible for common everyday tasks. The Etsy API in relation to stock and inventory makes little to no effort to achieve this. From what I can see the only way for an API consumer to update stock levels is to.....
- Make api calls to retrieve all their listings, then iterate over those listings to map listing ids to SKUs. (this could be multiple calls depending on the number of listings)
- Make further API calls per listingid to retrieve the listing inventory
- Iterate over the returned inventory and match each product_id with an SKU.
- Update the stock levels on the associated "offerings" for that product_id / SKU and then remove some returned elements (as mentioned in the tutorial page https://developer.etsy.com/documentation/tutorials/listings/#updating-inventory Notes 2) and then post the result to the updateListingInventory endpoint.
This is a mess and also highly prone to error as the updateListing endpoint seems to be implementing a replace strategy rather than an update strategy. This is further implied by the fact that it is using the HTTP verb PUT rather than PATCH.
I propose a simple endpoint for updating inventory stock levels based on product_id and or SKU. This should implement both GET and, PUT or PATCH requests and the GET methos should implement a filter by SKU THer should also be a way to retrieve all listing_id's and associated product_id's and SKUs which if designed correctly could possibly be made to work from the same GET endpoint.
I'm a consumer of this API like you, but I have to say: I think you're going about this the wrong way.
SKU is not a unique key for variants (aka products in Etsy parlance). I can make many listings that point at the same SKU. This is a good thing. SKUs are references into your database, and there's a 1:N relationship between variants (products) and "that thing in your database".
Shopify works the same way.
There's a lot of things to complain about, but this is not one of them. Maybe you're looking for a "search listings for something that references this SKU" endpoint? This seems like the kind of thing you should be tracking in your own database, but sure, it's a valid (if perhaps somewhat obscure) request.
I am not sure what your background is but in most systems an SKU (Stock Keeping Unit) is unique. Every variant of a product should have its own SKU as that is the definition of a Stock Keeping Unit it is used to track inventory movement and quantity. Having the same SKU for multiple variants of a product makes no sense at all... eg. How do you know how many Blue cups you have vs Green cups if they share an SKU? I work over many platforms and stock systems and the idea of a 1:N relationship between SKU and variations is not at all how things work in any major system where sock keeping of product variant is required. As an example, Amazon uses a unique SKU per variant and also per condition so... Your NEW Blue cup and your NEW Green cup have unique SKU's each as do your Signed Collectable Blue and Green Cups. They are 4 different items and therefore require 4 SKUs to track stock and sales.
Customisable products are however different in that you start with a base product with an SKU and then ad custom elements which makes a unique one-off product for a customer.
This is important and whilst I understand that everyone approaches things in different ways a large proportion of commerce is based on the SKU being unique to a specific product variation. My current project is maintaining stock levels across multiple platforms for a client and Etsy is the only platform that does not understand that an API needs to have a seller reference (aka SKU) that can be used to simply update stock levels and prices etc...
The mistake you are making is confusing your product with Etsy's listing. They are not the same things. Etsy's listings are bits of data at Etsy; the variants at Etsy are parts of the listing, and you can make as many listings/variants as you want (and are willing to pay for). These bits of data have a relationship with the actual products you have for sale, but are distinct. The SKU acts as a mapping - it is essentially a foreign key to your system. But it's not a 1:1 mapping, you can create multiple listings that contain the same item for sale.
This isn't just academic, it's common in at least two ways:
- If you delete or deactivate a listing and recreate it, the new listing will have some of the same SKUs as a prior listing.
- Cross selling, where you might add variants for related products to listings (and those variants are also for sale standalone).
Also, keep in mind that SKUs are not necessarily unique ids in someone's database. They could be compound values (eg PRODUCT-SIZE-COLOR). Some people don't even have databases and just put human-parsed data in there!
I work with many different ecommerce systems (including Etsy, Shopify, Woocommerce, and Amazon) and they all work this way. What platforms are you using?