Catalog Items API v2022-04-01->searchCatalogItems The response needs to return sellerSku

[468092882]

I am glad that you have improved the Catalog Items API, you can search through sellerSku, but after checking the response data, I found that sellerSku is missing, I hope that when the identifiers Type is SKU, the response data can return both SKU and ASIN, For sellers, the smallest unit is SKU, so that the business data of SKU can be matched with the data of the response.

At the same time, the ASIN data in some sites of the report type GET_MERCHANT_LISTINGS_ALL_DATA is missing. I hope you can investigate this problem. As the basic product data, if the ASIN is missing, the above problem will occur, and it needs to be supplemented elsewhere.

[littleylv]

When I call searchCatalogItems with some skus like skuA,skuB,skuC, it returns just asinA,asinB,asinC and I don't know which item corresponds to each sku.

Please return sku and asin both.

[chapmanjw]

@littleylv and @468092882 Thank you for pointing out this gap in the experience for the Catalog Items API. While not ideal, right now you could call one at a time to get an exact mapping to your input (so that there is no ambiguity until we implement something here).

From your perspective, where is the right place to inject the SKU into the response payload? There are a few places it could go, each with their own pros/cons. We would only inject it when it was an input parameter (i.e., we wouldn't lookup the SKUs you have for an ASIN and add the whole list on every ASIN, only inject the individual SKUs if it was what you requested it by). Additionally, since you can have multiple SKUs per one ASIN, it would end up being a list. So, we want to make this useful, but not confuse others when we don't populate it.

Option A: Top-Level

{
  "asin": "ABC",
  "skus": [
    "SKU_A", "SKU_B" // Assuming two SKUs requested that map to the same asin in this case.
  ], 
   "attributes": {}
}

Option B: Add to the Identifiers Upon Request

{
  "asin": "ABC",
  "identifiers": [
      {
         "marketplaceId": "...DER",
         "identifiers": [
              {
                  "type": "SKU",
                  "identifier": "SKU_A"
              },
              {
                  "type": "SKU",
                  "identifier": "SKU_B"
              },
              {
                  "type": "UPC",
                  "identifier": "...."
              }
          ]
      }
   ]
}

Or some other option....?

Option A puts the information right at the top-level of the response for easy access in client object models, but does limit future expansion of cross-marketplace query capabilities.

Option B puts the information alongside other marketplace-specific identifiers, enabling future expansion of cross-marketplace query capabilities without getting in the way, but the information is nested further within the payload.

Thoughts?

[chapmanjw]

Clarifying question on your use-case: Are you looking to retrieve ASIN data by SKU or are you trying to map SKUs to ASINs?

We are planning to launch a searchListingsItems operation on the Listings Items API in the future. This would include the ability to query SKU data by ASIN. Would expanding the searchCatalogItems operation here better suit your use-case or would launching the searchListingsItems operation?

[stefnats]

@468092882 currently your best bet to achieve a sku to asin mapping would be

1. Retrieve the merchant listing all data report
2. For missing ASINs retrieve some other report types for example fee preview report or call pricing Api or fee Api which also responds with the asin.
3. Then retrieve asin data from catalog items Api.

I think I read somewhere that a report type that retrieves all catalog item data for all listed items was in the making which would make all this extra work to one small step.

[midi-red]

I was going to create a new question but I feel like it is related to this one. As far as I can see, there is only one way to retrieve a seller's new listings without knowing SKUs, which is through the reports api. For example GET_FBA_MYI_ALL_INVENTORY_DATA returns all active/inactive listings. The assumption here is that I do not know the sellers SKU. I only know ASIN. I was wondering if there is another way to achieve this? Basically, what I want to know is if there is a way to be aware of a seller's new listings especially Inactive (Out of stock) status.

[littleylv]

@chapmanjw chapmanjw Sorry for my poor English.

From the MWS API GetMatchingProductForId, when I call some with params like IdType=SellerSKU, IdList.Id.1=SKU_A ... it returns <GetMatchingProductForIdResult Id="SKU_A" IdType="SellerSKU".

From your perspective, where is the right place to inject the SKU into the response payload?

I think option B should be better.

[468092882]

@littleylv and @468092882 Thank you for pointing out this gap in the experience for the Catalog Items API. While not ideal, right now you could call one at a time to get an exact mapping to your input (so that there is no ambiguity until we implement something here).

From your perspective, where is the right place to inject the SKU into the response payload? There are a few places it could go, each with their own pros/cons. We would only inject it when it was an input parameter (i.e., we wouldn't lookup the SKUs you have for an ASIN and add the whole list on every ASIN, only inject the individual SKUs if it was what you requested it by). Additionally, since you can have multiple SKUs per one ASIN, it would end up being a list. So, we want to make this useful, but not confuse others when we don't populate it.

Option A: Top-Level

{
  "asin": "ABC",
  "skus": [
    "SKU_A", "SKU_B" // Assuming two SKUs requested that map to the same asin in this case.
  ], 
   "attributes": {}
}

Option B: Add to the Identifiers Upon Request

{
  "asin": "ABC",
  "identifiers": [
      {
         "marketplaceId": "...DER",
         "identifiers": [
              {
                  "type": "SKU",
                  "identifier": "SKU_A"
              },
              {
                  "type": "SKU",
                  "identifier": "SKU_B"
              },
              {
                  "type": "UPC",
                  "identifier": "...."
              }
          ]
      }
   ]
}

Or some other option....?

Option A puts the information right at the top-level of the response for easy access in client object models, but does limit future expansion of cross-marketplace query capabilities.

Option B puts the information alongside other marketplace-specific identifiers, enabling future expansion of cross-marketplace query capabilities without getting in the way, but the information is nested further within the payload.

Thoughts?

Thank you very much for your reply: I think Option B: Add to the Identifiers Upon Request is more appropriate Of course, let's explore whether it is possible to put SellerSku in the outermost layer to map the ASIN data of this SellerSku, a mapping of SellerSku to ASIN

[468092882]

@468092882 currently your best bet to achieve a sku to asin mapping would be

1. Retrieve the merchant listing all data report
2. For missing ASINs retrieve some other report types for example fee preview report or call pricing Api or fee Api which also responds with the asin.
3. Then retrieve asin data from catalog items Api.

I think I read somewhere that a report type that retrieves all catalog item data for all listed items was in the making which would make all this extra work to one small step. Yes, my current process of getting the product list is the same as yours

[468092882]

@littleylv and @468092882 Thank you for pointing out this gap in the experience for the Catalog Items API. While not ideal, right now you could call one at a time to get an exact mapping to your input (so that there is no ambiguity until we implement something here).

From your perspective, where is the right place to inject the SKU into the response payload? There are a few places it could go, each with their own pros/cons. We would only inject it when it was an input parameter (i.e., we wouldn't lookup the SKUs you have for an ASIN and add the whole list on every ASIN, only inject the individual SKUs if it was what you requested it by). Additionally, since you can have multiple SKUs per one ASIN, it would end up being a list. So, we want to make this useful, but not confuse others when we don't populate it.

Option A: Top-Level

{
  "asin": "ABC",
  "skus": [
    "SKU_A", "SKU_B" // Assuming two SKUs requested that map to the same asin in this case.
  ], 
   "attributes": {}
}

Option B: Add to the Identifiers Upon Request

{
  "asin": "ABC",
  "identifiers": [
      {
         "marketplaceId": "...DER",
         "identifiers": [
              {
                  "type": "SKU",
                  "identifier": "SKU_A"
              },
              {
                  "type": "SKU",
                  "identifier": "SKU_B"
              },
              {
                  "type": "UPC",
                  "identifier": "...."
              }
          ]
      }
   ]
}

Or some other option....?

Option A puts the information right at the top-level of the response for easy access in client object models, but does limit future expansion of cross-marketplace query capabilities.

Option B puts the information alongside other marketplace-specific identifiers, enabling future expansion of cross-marketplace query capabilities without getting in the way, but the information is nested further within the payload.

Thoughts?

Report Type: GET_MERCHANT_LISTINGS_ALL_DATA Some stores in this report lack ASIN data, do you plan to deal with it? thanks

[discover59]

@chapmanjw How can I request several SKUs at a time if SKU has ,? For example, request with A,B SKU can check A SKU and B SKU and can return not found response. I am not sure how it works exactly. Would you let me know?

[chapmanjw]

@discover59

@chapmanjw How can I request several SKUs at a time if SKU has ,? For example, request with A,B SKU can check A SKU and B SKU and can return not found response. I am not sure how it works exactly. Would you let me know?

We are aware of the encoding issue with commas + comma-delimited parameters. Ideally, we would use encoded commas in the values with literal commas as delimiters (i.e., ?identifiers=SKU%2CABC,SKUDEF). Unfortunately, there is not a simple fix for this (yet). In the meantime, if you have a SKU with commas, we have special handling to search for SKUs using the comma-delimited values as well as the whole value, with the limitation you can only call for one at a time. For example, if you call with ?identifiers=SKUA,SKUB,SKUC, that comes to us encoded as ?identifiers=SKUA%2CSKUB%2CSKUC. In this scenario, we search for SKUs matching SKUA,SKUB,SKUC, SKUA, SKUB, or SKUC. While not ideal, this at least lets you work around the issue by submitting queries for one SKU at a time until we can resolve this issue permanently.

[chapmanjw]

For the original request, we have implemented Option B above. This should deploy sometime next week. When querying by SKU, the input SKU will be included in the identifiers section of the item responses when identifiers are requested in the includedData query parameter.

{
  "asin": "ABC",
  "identifiers": [
      {
         "marketplaceId": "...DER",
         "identifiers": [
              {
                  "type": "SKU",
                  "identifier": "SKU_A"
              },
              {
                  "type": "SKU",
                  "identifier": "SKU_B"
              },
              {
                  "type": "UPC",
                  "identifier": "...."
              }
          ]
      }
   ]
}

I will follow up and resolve this issue once deployed.

[chapmanjw]

For the GET_MERCHANT_LISTINGS_ALL_DATA questions, that report does not contain ASIN data. It only contains SKU data submitted by the merchant (any ASIN data there is what the merchant provided as part of their SKU data, not the reconciled ASIN data).

[discover59]

Is it possible to include reconciled ASIN value in report data? maybe asin column while asin1, asin2, asin3 are from seller?

[chapmanjw]

Is it possible to include reconciled ASIN value in report data? maybe asin column while asin1, asin2, asin3 are from seller?

@discover59 That report is scoped to "listings" data submitted by the merchant. Providing a report for "catalog" data (reconciled ASIN data) would be a separate feature altogether. I would suggest contacting Developer Support with your request (and why it is preferable over the APIs here) so that it can be forwarded to the product management team. Thanks.

[chapmanjw]

The change to add SKUs to the identifiers section when querying by SKUs has been deployed in all regions.

[ulandj]

@chapmanjw

We are aware of the encoding issue with commas + comma-delimited parameters. Ideally, we would use encoded commas in the values with literal commas as delimiters (i.e., ?identifiers=SKU%2CABC,SKUDEF). Unfortunately, there is not a simple fix for this (yet). In the meantime, if you have a SKU with commas, we have special handling to search for SKUs using the comma-delimited values as well as the whole value, with the limitation you can only call for one at a time. For example, if you call with ?identifiers=SKUA,SKUB,SKUC, that comes to us encoded as ?identifiers=SKUA%2CSKUB%2CSKUC. In this scenario, we search for SKUs matching SKUA,SKUB,SKUC, SKUA, SKUB, or SKUC. While not ideal, this at least lets you work around the issue by submitting queries for one SKU at a time until we can resolve this issue permanently.

https://github.com/amzn/selling-partner-api-models/issues/2433

I have the same issue when requesting multiple items using their SKUs and one of them has comma-delimited value. i.e.

identifiers=["square,4pcd,marble,", "ABC"]
identifiersType=SKU

in the url it look like this: ?identifiers=square%2C4pcd%2Cmarble%2C%2CABC&identifiersType=SKU&

I tried to escape values which are contain commas and make request with query params: ?identifiers=square%252C4pcd%252Cmarble%252C%2CABC&identifiersType=SKU&

x-amz-date: 20220808T131156Z
x-amzn-requestid: 62e0ae74-a2dc-4329-afd3-da50b002bbcb

But both of requests return item with SKU=ABC only. Do we still need to request an item where SKU with commas individually(one at a time)?