[FEATURE]: To add Listing Properties as Includes in Batch Listings endpoint

[switmac]

Is there an existing ticket for this?

• [X] I have searched the existing tickets

Is your feature request related to a problem? Please describe

I'm anxious with the amount of API calls that we need to do in order to get the properties for a batch of listing call. Sample, when we need to call 100 listings in a batch API and wanted to get the properties for each listing then we will need to make 100 api calls for each listing to getListingProperties in order to obtain this data.

Describe the solution you'd like

We can add Properties as includes in the batch endpoint https://developers.etsy.com/documentation/reference/#operation/getListingsByListingIds

Describe any alternatives you've considered

The only way to achieve this right now is to call the getListingProperties endpoint for each listing. https://developers.etsy.com/documentation/reference/#operation/getListingProperties

Additional context

For shops that have many listings, that will mean 1 listing is to 1 api call. I worry that this will heavily affect on the api call limit that is given and can be easily exhausted.

[etsyachristensen]

@switmac Thanks for the request. I have a few questions:

1. When you are querying the listings by a list of ids, how are you getting the list of ids in the first place? I'm curious if there's a way that the source of those ids could be used to cut down on some of the calls you have to make.
2. When you make the calls to the API for this endpoint are you passing an OAuth token or only the api_key? The reason I ask is that if you include an OAuth token for the shop that you are requesting this data on behalf of, the rate limit will go against that seller's rate limit. So if you have 10k global api calls per day, each seller also has an allotment of 10k per day. So making the call with a token won't go against your limit.

That all being said, I don't think it is out of the realm of possibility to add Properties as a possible include, but I can't make a guarantee either way. What I can do is add it to our list of suggestions for future development.

[switmac]

hi @etsyachristensen , thank you for noticing this request.

here are the answers to your questions:

1 We get the 100 listing ids from https://openapi.etsy.com/v3/application/shops/{shop_id}/listings/active and since we cannot get all the data that we need from here, we will make another call to https://openapi.etsy.com/v3/application/listings/batch to get the includes data such as "Images" "Translations" "Inventory"

2 When making the api calls mentioned above, we only pass the api_key. For shops that have more than 100 listings that will make total # of listing calls to the api. Aside from the concern in limit, we are also worrying with regards to the processing time since 100 api calls to Etsy server per 100 listings of the Shop is a lot and we will at some point encounter looping this until all the listings will have the properties data.

I appreciate that you have added this in the future development list. Hoping that this might be available before the sunset of v2 as it is fast approaching. :)

[nateswart]

Hi @switmac - can you help us understand the larger business workflow or feature you are building?

[etsyachristensen]

@switmac Can you get back to us on the question from @nateswart above?

[chrisrogala]

@nateswart and @etsyachristensen Since @switmac is not responding, I will respond with our business scenario.

Last year, the Listing endpoint was missing a lot of associations we had in the previous version of the API. Because of this, the direction Etsy given (https://github.com/etsy/open-api/issues/96#issuecomment-908496904) to developers was to call the Listings/Batch endpoint (v3/application/listings/batch) since it had the includes query parameter. I explained the same exact scenario that @switmac is explaining here in this comment: https://github.com/etsy/open-api/issues/96#issuecomment-908479618 I even mentioned the listing properties in the comment on 8/30/2021. The original author of that issue also mentioned Properties in the why section of the request.

In this case, it looks like @switmac is only trying to pull the Properties into his application but the Properties can only be pulled from the individual listing. In our shop, we have over 300 listings. If I tried to pull the properties, it would currently take 300 calls to get this information. These properties are important for customers to determine if they want to complete a purchase. The properties include:

• orientation
• framing
• rooms
• primary color
• art subject

These properties are all vital in the customer decision process. For now, we are not pulling those into our application. So if there is a business case needed, then it's simply increased sales for Etsy.

The reality is, associations were vital to numerous applications in v2. When v3 was originally designed, the architect designed very strict RESTful services which made the services a lot more chatty but the allowances provided by Etsy did not change to account for the additional calls. Because of this, it has been an ongoing process to request associations be added throughout the last two years.

One way to solve for this is the use of webhooks. If Etsy offered webhooks, like Shopify and other ecommerce sites, then developers would not have to poll Etsy to locate modifications. With costs tightening, I would love to not pay for the processing time needing to find the modifications. Webhooks would reduce my costs associated with logging, support, processing, networking, etc. It would also help to eliminate a lot of these requests. We are a small company, but imagine the cost savings from Etsy's infrastructure. Our current daily requests would like drop from a few thousand to potentially less than 100 for our individual store.

Either way, it would be very useful if Etsy would evaluate the associations we had in v2 and add them into v3. I'm attaching an image from the docs below as a reference. Cheers!

[switmac]

hi @nateswart @etsyachristensen

we have exactly the same case with @chrisrogala . thank you for expounding my thought. :)