Use case not supported - Githubissues

teddy-codes commented 3 years ago

Good Afternoon,

I am creating this issue to note that a use case that is used by many sellers and applications is no longer supported. You cannot retrieve multiple identifiers in one request. The /catalog/2020-12-01/items endpoint seems to be an AND operator. This endpoint was apparently the replacement for GetMatchingProductsForId, but you can no longer send multiple identifiers.

kpconnell commented 3 years ago

What use case isn't supported? Seems like more of a performance concern than anything else considering you can just loop on your identifiers.

teddy-codes commented 3 years ago

Yes, I was mistaken as the use case not being supported. This is definitely a performance concern and it's blocking us from moving to the sp api. We now have a set deadline of March 31st to move, but this performance issue is causing us to delay that move. I would like to see this issue fixed prior to our attempt to migrate.

chapmanjw commented 3 years ago

@teddy-codes The SP APIs for Catalog Items are explicitly not bulk requests. We do not have any plans at this time for a "bulk" or "batch" version of the Catalog Item APIs. Beyond throughput rates, are there other reasons why making individual calls in parallel would not suffice for your use-case?

As far as throughput rates go, please open a support case so that we can discuss your specific needs in more detail: https://sellercentral.amazon.com/gp/mws/contactus.html.

teddy-codes commented 3 years ago

@chapmanjw thanks for your response.

For the SP API being a new API which is supposed to replace MWS, it's garbage. When making the API, I believe sourcing of products was not taken into consideration, so please go back to the team and inform then of this use case (... should have been thought of) and let me know when something changes.

In regards to making the requests in parallel, the throttle for the searchCatalogItems request is only be 1/second, so there really is no point in doing that... would just get throttled until it was eventually ready and then return. Not quite sure if there is any gain there. There is actually just a cost of network traffic on both sides.

If there was a request introduced that replaced GetMatchingProductsForID, instead of just replacing ListMatchingProducts and hoping that it works, that would be ideal.

Also, there is no identifier search. Which absolute clown thought of that?

chapmanjw commented 3 years ago

@teddy-codes Can you elaborate on the use-case you are referring to with sourcing of products was not taken into consideration?

For the throttle rates and parallelism, what throughput rate would alleviate the concern?

GetMatchingProductsForID and ListMatchingProducts are both search operations and neither matches the behavior of Seller Central (they are both actually keyword searches). The searchCatalogItems consolidated this functionality into a single keyword search that behaves the same way as Seller Central (the search page that is used when adding a new product to your catalog).

teddy-codes commented 3 years ago

The use case is sourcing products and trying to weed through the whole Amazon catalog to find products to resell. Sellers go to conventions and talk with hundreds of brands to get items to search eventually get down to a few brands that they will actually source from. Note: these searches have to be done in a timely manner to meet deadlines for show specials, etc. Some distributors have upwards of 100,000 items.

For throttle rates, it really would have to get close to what GetMatchingProductsForID currently is to ensure there is no negative user feedback. If there was a bulk operation possible (such as passing up to 5-10 keywords/request), but with the same throttle limit, this is fine. Our workloads are batched as you could imagine, so that might also be something to take into consideration when creating a throttle formula. The current burst for the searchCatalogItems request is 5.

The two requests acted very differently (which was a good thing). One had a small throttle limit with a keyword search which was fine since it was not used remotely the same as the identifier search. GetMatchingProductsForID was the ideal request for our use case as it allowed for a batch of 5 identifiers and it allowed for a significant amount of requests (18,000/hour vs the new 3,600/hour).

When Amazon goes to source a brand to sell, I am so certain that there is no employee that goes to the add a product page to search an identifier as it simply doesn't scale, so please export this functionality to the third party sellers that the api was designed for.

chapmanjw commented 3 years ago

@teddy-codes Thanks for the details on the use-case, that is helpful. Our team is working on scaling and configuration to support higher throughput than the 1 TPS currently configured (at a minimum to cover the combined throughput of the two previous APIs).

Diving into the use-case you're describing a bit more, it sounds like there may be an opportunity here for a different solution altogether. Querying 100K items is going to be time consuming, regardless if 1 or 5 at a time. Thinking out loud, something more useful here might be a truly bulk solution, such as a feed that accepts the list of items requested and responds with a processing report containing similar data to the Catalog Item APIs. Or perhaps some asynchronous query features on the Catalog Item APIs that reply with a push notification once complete. In either case, something that accepts a very large request, processes in async, and replies with a very large response.

If we built such a feature, what specific data would you need from the Catalog Items APIs to support this sourcing and reselling use-case?

teddy-codes commented 3 years ago

That would be amazing. There are quite a few things that we would still have to query outside of the catalog api such as the current buy box price and fees, but definitely a good start with the catalog items api (the other requests are not awfully throttled, but definitely could use a bulk request as well).

We would need:

ASIN
Title
Brand
Sales Rank (in the parent category)
Category
Package dimensions (height, length, width, weight and weight unit)
Package quantity (although it is always wrong... the quantity ends up being in the title)
Size
Color
Variation Parent

kpconnell commented 3 years ago

@chapmanjw also thinking out loud here in terms of limited resources on your side, there are a lot higher value business processes and seller models that exist beyond arbitrage blast mining that the api could support better - inbound box contents is dumb and slow, finance is way too complicated with the superset of global transactions, still nothing to download business reports metrics like parent page visits.. the list goes on. I'd hate to prioritize what is candidly the model that brings us to ebay.. counterfeit goods and unauthorized distributors galore. just my $0.02.

chapmanjw commented 3 years ago

@teddy-codes Thanks for that. Looks like there are a couple of items there not currently covered by the API itself (which I've made note of). I will forward this to our product manager.

chapmanjw commented 3 years ago

@kpconnell I am an engineer on the Amazon Listings team. For Selling Partner APIs, my particular purview is on the Listings (SKUs), Catalog (ASINs, Categories), and Definitions (Product Types) related APIs. For the business processes and use-cases you are referring to, we'd love to get your feedback on where we can better serve those use-cases. In particular, those related to managing listings on Amazon and the supplementary features needed to better automate listings workflows. Thanks!

teddy-codes commented 3 years ago

@kpconnell We are actually one of the largest wholesale sourcing software for Amazon sellers, so please don't assume that arbitrage is the only form of reselling. The wholesale model is the only model that we allow on our platform to ensure focus. I understand that other sections of the API are not the most ideal at this moment, but the products section of the MWS API is being removed as of March 2022 and if this is not implemented, then our users will not be able to source at previous speeds and therefore potentially missing opportunities while at conventions.

@chapmanjw Thanks for forwarding this to your product manager. The only reason that things like variation information is required is because Amazon doesn't require that a single UPC connects to a single ASIN and therefore, there can be variations with both the color white and black and/or just white with the same UPC. This is also super difficult to deal with. Anyhow... whichever route is taken to fix this issue and provide the data necessary to wholesale resellers, please notify me here so I can implement it into our app prior to the removal of the Products API.

araup006 commented 3 years ago

@kpconnell Your comments about resellers are false (and rude tbh). Your comments about other SP API issues are completely irrelevant to the catalog api. Please open a new issue with your concerns. Retailers that sell products on the Amazon platform depend on the MWS Products API and this performance issue needs to be addressed.

txphi592 commented 3 years ago

@chapmanjw Completely agree with @teddy-codes comments, we have the same use case and run one of the most popular apps in your app store. With our app, we support thousands of Amazon businesses that rely on this use case for their livelihoods. It's alarming to us that Amazon has yet to consider one of the most popular sourcing methods (Wholesale) when developing an API to replace MWS. I'm hopeful that this thread is a wake up call and the bulk use case is added to the development scope ASAP.

We would be happy to help in any way we can by providing more detail and feedback to ensure this gets implemented in the most optimal way. Thank you for your attention to this and please keep us updated as we cannot begin a migration to SP-API until this use case is properly supported.

teddy-codes commented 3 years ago

@chapmanjw If you direct people to seller support, please make sure that they have even a clue what they are talking about... I understand that Amazon is a large corporation and has a lot of moving parts, but this is one reason why we had chosen to build an app for Amazon sellers. Here is my response from them:

Hello from Amazon Selling Support,

Thank you for contacting the MWS Support team with your concern about throttling. Throttling limits are listed under the API documentation, generally under the heading of each section. For instance, for the Products API you can find all throttling information at http://docs.developer.amazonservices.com/en_UK/products/Products_Throttling.html. If it's not under the heading, you can check the specific operation and often the throttling limits are in the first couple paragraphs. We cannot provide a throttling increase and recommend following the best practices as listed below in addition to documentation on our Developer website to ensure you have a scalable software. Best practices:

Avoid submitting a lot of feeds with only a few records in each feed. When possible, combine the data into less frequent larger feeds.

Include only the products you are updating, not your entire inventory.

Upload one feed of the same type no more than once every 20 minutes. Allow more time between larger feeds.

Keep file size below 10 MB

To help us continually improve, we ask that you take a moment to complete our survey below to tell us about your experience with this specific interaction.

Were you satisfied with the support provided?

With this being the first line in my conversation.

seller support -> 🤡

It's unfortunate that this is the way that Amazon communicates with sellers to talk about their use case and such while the removal of an API is among us. Please forward these details to whoever manages seller support and hopefully there is a dedicated developer advocate team formed.

For reference, the case number is: 8624279801

teddy-codes commented 3 years ago

At the end of this comment, I am going to rename the issue back to the original name because this is not really a performance issue, but rather a use case issue as I had noted titled this issue. We now have 3 different businesses which have commented on this issue who are trying to follow the guidelines set by the MWS Developer TOS (and whatever terms the SP API has). There are other software which do similar things to all of us, but are collecting data outside of using MWS.

Imagine... No throttle... No API changes... No keys to manage... Just a site that you go to in a browser to collect this data.

There should absolutely be a bulk search functionality and/or sensible throttling to ensure that our use case is supported. Otherwise, you will find that software companies who do this legitimately will be weeded out in favor of those who I have mentioned above.

txphi592 commented 3 years ago

At the end of this comment, I am going to rename the issue back to the original name because this is not really a performance issue, but rather a use case issue as I had noted titled this issue. We now have 3 different businesses which have commented on this issue who are trying to follow the guidelines set by the MWS Developer TOS (and whatever terms the SP API has). There are other software which do similar things to all of us, but are collecting data outside of using MWS.

Imagine... No throttle... No API changes... No keys to manage... Just a site that you go to in a browser to collect this data.

There should absolutely be a bulk search functionality and/or sensible throttling to ensure that our use case is supported. Otherwise, you will find that software companies who do this legitimately will be weeded out in favor of those who I have mentioned above.

Absolutely, this is exactly what will happen. Unless this use case is addressed ASAP, half of the apps in the Product Research and Scouting section of the Amazon app store will be forced to go out of business or start using 3rd party APIs which violate Amazon terms (since they scrape/resell Amazon's data).

Please help!

teddy-codes commented 3 years ago

This is an update that I had received from seller support who pointed me back here. Please.... someone should take over seller support questions related to the SP API that has any clue what they are talking about.

I started a chat from our seller account to provide use case specific problems that we are facing with the new sp api and seller support first pointed me to mws and then pointed me to the sp api documentation. Please... How is a migration by March 2022 even reasonable?

dkt2000 commented 3 years ago

We have the same issue in searchCatalogItems (SPAPI) which is going to be a big problem for us as well as many other developers/apps/sellers. Since SP-API is not supporting our use-case right now, we are stuck and can’t proceed with migration from MWS to SP-API. Please advise since we have a looming deadline…

SearchCatalogItems (SPAPI) does not support bulk operation.
Many wholesale sellers depend on this function to process bulk product lists from their suppliers. This can amount to thousands of products to hundreds of thousands of products that have to be processed. Without bulk operation, this is not really possible and will impact a huge segment of Amazon sellers (wholesale sellers). SearchCatalogItems (SPAPI) quota is 1 request per second or 3,600 per hour vs GetMatchingProductsForId (MWS) is 18,000 per hour.
GetMatchingProductsForId (MWS) response provides important product parameters that we use in our apps and sellers need (listed below). Many parameters are missing in SearchCatalogItems (SPAPI) response.

• ASIN • Title • Brand • Sales Rank (in the parent category) • Category • Package dimensions (height, length, width, weight, and weight unit) • Package quantity • Size • Color • Variation Parent • Product Group • Part Number • Model Due to these restrictions, we are not able to migrate our application from MWS to SPAPI, and SPAPI customer support has been useless.

We don't know what to do in this situation.

teddy-codes commented 3 years ago

@dkt2000 Just so that you know, @chapmanjw replied to my other issue here: https://github.com/amzn/selling-partner-api-models/issues/1663

He confirmed that all of the attributes that I am requesting will be available. There are some attributes which I did not request such as Product Group, Part Number and Model, but I believe that this is essentially where most people put additional package quantity information to make the listing their own. This is vital information of a listing and are requesting this information as well.

This is still a huge blocker for us as the deadline is approaching and we are unable to allocate any development time to this as it would be a waste of time while not knowing what will be supported and what won't be.

@chapmanjw Are bulk operations in your roadmap? Do I have to go look for alternative sources for this data?

teddy-codes commented 3 years ago

@chapmanjw can you confirm for me that v0 will have a new version branched off of it prior to the deprecation of it in March 2022?

chapmanjw commented 3 years ago

@teddy-codes We will have an updated version (extending the 2020-12-01 version) prior to the deprecation of v0 based on your and others feedback. I will hopefully have more to share on that soon.

teddy-codes commented 3 years ago

@chapmanjw Thank you for the response. The 2020 version currently does not have the throttling that v0 has. The v0 doc matches what you said with combined throttling of the two requests which makes me even more confused...

It is unfortunate that we are in limbo about this while the deadline is approaching.

txphi592 commented 3 years ago

@chapmanjw Thank you for the update. Can you confirm that the recent throttling updates and attribute additions made to v0 will make it into the new extension of 2020-12-01 that you mentioned would be released prior to the deprecation of v0?

Also, it would be extremely helpful if you can share any guidance re: the expected release of such update as we are concerned that we would need enough time to implement the new API AFTER the changes are made but PRIOR to the deprecation of MWS Products in March of 2022.

As @teddy-codes mentioned, we're also in limbo. We cant really do much right now since the current version does not support the use-case. we don't know how things will change and when those changes will occur. I hope you can appreciate that this lack of clarity is paralyzing.

Thanks again, your communication in this case is extremely helpful to clear up the confusion.

gokigoks commented 3 years ago

Same issue we are running into while migrating. The throttling is much lower while not allowing searching in bulk.

Also, there are a few other endpoints (lowest offer, competitive pricing, fees estimate, etc.) from the old MWS API with no counterpart on the SP-API, are they going to be dropped?

Another issue with the catalogs API is the brand affiliation requirement causing another roadblock.


"errors": [
    {
      "code": "InvalidInput",
      "message": "FORBIDDEN",
      "details": "The includedData requested requires Brand Registry affiliation with the requested item. Remove the requested includedData item or register the brand of the item in Brand Registry with the seller."
    }
  ]

teddy-codes commented 3 years ago

@gokigoks Thanks for the support on this issue! I believe that the pricing/fees requests are now separated into their own apis subsection.

Fees: https://github.com/amzn/selling-partner-api-docs/blob/main/references/product-fees-api/productFeesV0.md Pricing: https://github.com/amzn/selling-partner-api-docs/blob/main/references/product-pricing-api/productPricingV0.md

jamescurrer commented 3 years ago

I'm also waiting for news on this release, as our use case (described in issue amzn/selling-partner-api-models#1663 ) is not supported by the 2020-12-01 version either.

Many thanks @chapmanjw for your input, it's great to know someone from the dev team is hearing us!

chapmanjw commented 3 years ago

@teddy-codes We have updated the 2020-12-01 version of the Catalog Items Get API to no longer require brand affiliation with an ASIN in order to retrieve the raw attributes data set. Requesting the attributes data set will return all attributes for an ASIN that are defined by the Product Type Definitions API for the product type of the ASIN. As we are in-progress of migrating product types to the APIs, some ASINs will continue to rollup to the PRODUCT product type for the available attributes and only include the attributes that are defined on the root PRODUCT product type.

While the attributes data will assist in inspecting the "raw" attributes for an ASIN, it is unmodeled data and is not ideal for some use-cases depending on modeled data (i.e., modeled in the Swagger model). With that in mind, we do still plan another release where additional details are added to the Swagger model of the summaries and variations sections.

Thanks for the feedback thus far and helping us to refine this product!

teddy-codes commented 3 years ago

@chapmanjw Thank you for your continued support with this migration.

I will be closing this issue and will open other issues as problems arise.

Thank you to everyone for their continued support on this.

teddy-codes commented 3 years ago

Actually, I am reopening this issue as our response from developer support was less than ideal about throttle rates (which is the original reason why I had opened this issue).

The seller partner specific throttling. Is this developer specific? Do all of our users have to request an increase in limits? How will this work?

In my opinion, the throttling should be developer specific and apply to all API requests.

@chapmanjw Do you have any insight on this?

kpconnell commented 3 years ago

the throttles are app and merchant specific which is what they should be. a developer specific throttle would be disasterous.

On Fri, Sep 24, 2021, 8:32 AM teddy-codes @.***> wrote:

Actually, I am reopening this issue as our response from developer support was less than ideal about throttle rates (which is the original reason why I had opened this issue).

The seller partner specific throttling. Is this developer specific? Do all of our users have to request an increase in limits? How will this work?

In my opinion, the throttling should be developer specific and apply to all API requests.

@chapmanjw https://github.com/chapmanjw Do you have any insight on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/selling-partner-api-models/issues/1563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZRUKFURXV3C2BDHR7LUDSDWJANCNFSM47VJCFXA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

teddy-codes commented 3 years ago

I would not like all of our users to be required to contact seller support for a rate increase when they use our application. It doesn't make sense from a ux perspective to require this. Let me provide you with an example of this...

Let's say that there are two users. One user who is a small seller and doesn't use their throttle limit, so no problems there. The other user is a medium size and constantly hits this throttle limit. How would we effectively increase their limit without contacting seller support and going through the headache of asking for use case, etc. per seller?

teddy-codes commented 3 years ago

If and only if @kpconnell is talking about one developer needing to make requests for all sellers that use their app with their own throttle rates (and use their own bucket), then I will agree. This is not what I am talking about though. I am talking about having a developer throttle rate per seller (essentially every seller id will get a throttle rate), but defaulting to the throttle rate of the developer (whichever is higher).

kpconnell commented 3 years ago

no it is not.

On Fri, Sep 24, 2021, 11:22 AM teddy-codes @.***> wrote:

And why is that?

The current setup with MWS is developer specific.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/selling-partner-api-models/issues/1563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZRHWZQHJYJI6QXRCTDUDSXV5ANCNFSM47VJCFXA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

jamesp26 commented 3 years ago

@chapmanjw - This is an amazing amendment. This has also fixed issues we had where sometimes the images resulted in brand affiliation issues. Will you be updating the documentation with the newer rules?

limenote135 commented 3 years ago

I opened a support case to solve this throttle issue, but Amazon closed the case because "SP-API is not for finding out which products to procure in advance, but for products you already have".

teddy-codes commented 3 years ago

@limenote135 You should talk with them again to see how they are going to provide us with this functionality if that is their answer.

Seems quite ridiculous.

limenote135 commented 2 years ago

I totally agree with you but according to their response, 1 rps is enough even if it is used to sourcing products. And I reopen or recreate cases to inquire about this and previous response (https://github.com/amzn/selling-partner-api-models/issues/1563) but all of them are closed WITHOUT any responses, so all I can do is laugh 🤣 🤣 🤣

Has anyone been accepted to increase the rate limit?

chapmanjw commented 2 years ago

I totally agree with you but according to their response, 1 rps is enough even if it is used to sourcing products. And I reopen or recreate cases to inquire about this and previous response (#975 (comment)) but all of them are closed WITHOUT any responses, so all I can do is laugh 🤣 🤣 🤣

Has anyone been accepted to increase the rate limit?

@limenote135 Can you provide me with the case id for your request? Researching products in the Amazon catalog is a use-case we support. I will follow up with the support team on the case.

chapmanjw commented 2 years ago

@teddy-codes @limenote135 and everyone else on this thread,

On a related note, we are considering a further modification to the Catalog Items API related to the attributes data we return when the product type is not yet launched in the Product Type Definitions API and Listings Items API. I've posted a poll here, would love your feedback:

[Poll] Catalog Items API - All Attributes or Editable Attributes?

Thanks!

limenote135 commented 2 years ago

@chapmanjw Thank you for your help. #2248651033 is the case number but this is on Amazon.co.jp.

chapmanjw commented 2 years ago

@limenote135 Following up with the support team. Thanks.

teddy-codes commented 2 years ago

@chapmanjw I saw in the documentation for the searchCatalogItems operation in the 2020 version that the attribute field is still only available to brands. This is still a blocker for us to move to the sp api. We are in need of these key datapoints:

package dimensions
manufacturer
part number
package quantity
title

These are not the only ones, but it's the short list that I can come up with now. Is there a plan for this to be available to us in the near future so we can successfully make this migration?

txphi592 commented 2 years ago

@chapmanjw, We started the process of mapping the data we currently consume from MWS to the data available in GetCatelogItems & SearchCatelogItems in SP-API. As part of that exercise, we discovered issues that would be show-stoppers for us as well as many other Amazon apps.

These issues have to do with attributes that we need and currently consume from MWS that are seemingly not available in Get/Search. In some cases, certain attributes may be available in Get OR Search but not both which is equally as problematic. Ideally, we can shore up Search to support all of the missing data since Search supports all of the required Product Identifiers (ASIN, UPC/EAN & ISBN) while Get only supports ASIN (which does not work for us practically speaking since most users of our app are doing product research based on non-ASIN identifiers).

See attached spreadsheet which maps our needs vs availability in SP-API to make the issue clear. Please note the Color Key in column H. Data Mapping and Needs.xlsx

Also, on 9/29/21 we received an email from Amazon (dev-reg-notice@amazon.com) indicating that Amazon “will be extending the date for when the Products API will be deprecated. In the coming weeks we will be posting a MWS deprecation roadmap to provide visibility and help developers plan their migration efforts for next year.” We have not seen such a roadmap published and have not seen a new deprecation date. Any insight on this? It’s important for us to understand the deadline for deprecation.

Thanks so much for your help and happy Thanksgiving! 😊

teddy-codes commented 2 years ago

@chapmanjw I don't even see attributes as an available includedData argument. Is this just undocumented?

https://github.com/amzn/selling-partner-api-docs/blob/main/references/catalog-items-api/catalogItems_2020-12-01.md#includeddata-subgroup-2

I agree with @txphi592 that it is important that we discuss the moving of the deprecation date as the data is approaching fast without any real answers to our questions. How can we resolve this? (see amzn/selling-partner-api-models#1698)

Is the plan with search to simply allow us to gather ASINs from an identifier and then use get to retrieve information about the ASIN? Seems like a waste of network traffic, but if that's what is warranted, I can do that.

Happy Thanksgiving!😄

m8labsteam commented 2 years ago

Crickets... ::BUMP:: Teddy already finished his Thanksgiving and now we're fast approaching New Jedi Order era according to the Wookieepedia.

jamesp26 commented 2 years ago

Accidentally put this in a closed message, so adding here too. Any ideas?

We are in the latter stages of migrating from getMatchingProductForId over to getCatalogItem. However, 2 fields that were essential for our reporting back to clients were

Flavor Scent I cannot find these in summaries or the attributes. Interestingly, 'Color' is available in summaries.

Is there another way i should be getting these attributes (Flavor, Scent)? We only need them for the brand owners and it seems logical that they should be available in the getCatalogItem request. Thanks for any help.

chapmanjw commented 2 years ago

@teddy-codes The search operation does not currently include attributes as the get operation was intended to be used for getting the extended data. However, to facilitate the migration off MWS APIs, among other reasons, we will be making a few changes to the Catalog Items APIs (I don't have a specific timeline I can share, however, just that this is what's coming):

The Search API will include the attributes section (making it the only call you'll need to make, not needing to use the get API unless you are getting a single item and already know the ASIN).
The Search API will have an identifiers parameter to query on one or more product identifiers explicitly and return whichever ASINs are found (this would effectively allow for batching of GET requests, but remain RESTful in nature).

These changes in addition to adding more data to the summaries and variations data sections that will be made available in both the search and get operations.

limenote135 commented 2 years ago

@chapmanjw What kind of identifiers will be able to set? In our case, We are using GetMatchingProductForId API to get asin from EAN code but searchCatalogItems may return different items. For example, if the item has variations, searchCatalogItems returns only parent asin.

chapmanjw commented 2 years ago

@limenote135 Unlike the MWS GetMatchingProductForId, we don't actually need a parameter that disambiguates the type of product identifier. As such, we will have the identifiers allow a list containing ASINs, UPCs, EANs, JANs, ISBNs, (maybe more?). From there, we will return any found items that have one of those identifiers.

amzn / selling-partner-api-models

Use case not supported #1563