Release: Amazon E-Commerce Service on 2006-11-14

Release Notes>Product Advertising API>Release: Amazon E Commerce Service on 2006 11 14
This release of Amazon ECS adds two search indices to the US locale: Grocery and HomeGarden. The ListPrice value in the DE locale was also corrected.


Submitted By: Craig@AWS
Created On: November 14, 2006 10:45 PM GMT
Last Updated: November 17, 2006 3:07 PM GMT

These release notes provide a summary of all New Features and Resolved Issues in the latest version of Amazon's E-Commerce Service (ECS). For changes made in previous ECS versions, go to

To receive notification of future releases automatically, go to

Release Date: 2006-11-14
Latest WSDL/API Version: 2006-11-14

New Features

The following table describes the new features found in this release.



Search Indices
Home Garden

Two new search indices, Grocery, and Home Garden, are now supported in the US locale.

Resolved Issues

The following table describes the issues resolved in the latest release of ECS.




In the DE locale, the ListPrice returned was incorrect. This problem has been fixed. Most items, however, do not have ListPrice values.


Known Issues

The following issues describe irregular behavior seen in ECS 4.0 functionality:

The BrowseNodeLookup operation often returns inaccurate results for top sellers when the browse node in the request is the root node of a category. The workaround is to use one of the child browse nodes with the TopSellers response group.

Some of the browse node IDs listed in the ECS Developer Guide are out of date.

The ListFull and ListInfo response groups sometimes return an incorrect value for TotalItems. The discrepancy arises when the response sometimes includes invalid ASINs as part of the total.

Images may not be returned if the MerchantId parameter is not specified in the request. The default value for MerchantId is Amazon. If the item returned is not being sold by Amazon and Amazon has no images for it, the response will not include images without MerchantId being defined. For example, the following request will not return images if the MerchantId parameter is removed.
AWSAccessKeyId=[Access Key ID]&

Items returned by ItemSearch may have prices that fall outside of the range specified by MaximumPrice and MinimumPrice. The ItemSearch parameters, MaximumPrice and MinimumPrice, should limit the items returned according to the specified price range. Sometimes, items are returned whose prices fall outside of the specified range.

ItemSearch requests based on Actor or Director return the same results.

Salesrank values in the CA and EU locales do not match the values returned by the retail website in those locales.

The Cart response group should return SellerNickname but does not.

Not all parent browse nodes are returned by BrowseNodeInfo. The response group, BrowseNodeInfo, used in BrowseNodeLookup requests returns the child and parent browse nodes of the browse node specified in the request. When a browse node has multiple parents, however, only one of the parent browse nodes is returned in the response. That is why there might be a difference between the ECS response and the result displayed on Amazon’s retail web site. BrowseNodeInfo returns the entire lineage of both child and parent browse nodes. For example, in the following response snippet, the parentage of the browse node in the request, Social Sciences, is traced all the way up the browse node tree to the root browse node, Books. Also, all of the children of the node, Social Sciences, are returned. For the sake of brevity, the following response snippet shows only some of the returned child browse nodes.

   <Name> Social Sciences</Name>
- <Children>
  - <BrowseNode>
  - <BrowseNode>
  - <BrowseNode>
      <Name>Children's Studies</Name>

Notice that all of the nodes in the response show only one parent node, for example, the parent node of Social Sciences is Nonfiction. Only a single parent node would be returned even if a node had multiple parents.

Items sorted by salesrank are returned out of order. In an ItemSearch request where Sort=salesrank, you would expect the items to be returned in order of their sales rank from best (1) to worst (large number). The sales rank values for items change frequently. The ECS sales rank updates lag behind the sales rank updates on the retail website. So, in an ItemSearch request, although the sales rank numbers are out of order in the ECS response, the items are, in fact, ordered according to the sales rank computed on the retail website. In this way, the sales rank order of items returned by ECS and Amazon’s retail website match. One alternative in the US locale is to use the TopSellers response group to get the top 10 bestsellers. Those items are returned in order.

ItemSearch power searches sometimes return different results when the sort parameter is specified versus when it is not specified.

Cart functions fail with items found using the Wireless search index. Items found using the Wireless search index cannot be added to remote shopping carts because these items require the selection of various options and phone plans. Information about these options and plans is not available through ECS.

The parameter, pubdate, which is used in ItemSearch Power searches is not working correctly. This parameter sometimes does not return results for the specified pubdate value when it should.

When a customer has multiple lists of the same type, ListSearch returns only one of the lists.

Changing access to lists often requires up to twenty-four hours to take effect. Only public lists are returned by ListSearch. The search index, however, is only updated once every 24 hours. So, it is possible that, for up to 24 hours, the list ID will be available through ECS ListSearch even though a ListLookup on that ID will fail.

Relevancy rank does not work with blended searches. Relevancy rank generally corresponds with sales rank. Currently, the relevancy rank using ItemSearch blended searches yields inaccurate results.

Updating the availability status of a few items takes exceptionally long. There is a lag time incurred for the availability status of an item to be updated. For a few items in each Search Index, however, those lag times are exceptionally long.  These lag times account for inaccurate availability information, even when the ItemSearch parameter, Availability, is set to "Available." To check the true availability of an item, use the Offers Response Group. If an offer is returned for an item, it is truly available.

If the same ASIN exists in both the US and CA and is available in only one of the locales, ItemSearch shows that the item is available in both locales. For example, for an ASIN that is available in the US but not in CA, ItemSearch might return that it is available in the CA locale.

ItemSearch using the SearchBins Response Groups sometimes breaks.  When the SearchBins Response Group is used with ItemSearch, in rare cases, a bin name is not returned, which does not conform to the schema.

ItemSearch sometimes returns items sold by Amazon and other merchants when Amazon is passed in as a string. When you use ItemSearch and the Availability parameter is not used, and MerchantId is set to the string, “Amazon,” ItemSearch returns items sold by Amazon and other merchants, which is incorrect. Setting the Availability parameter to “Available,” however, makes ItemSearch correctly return items sold only by Amazon.

GZIP functionality not working. XML responses are not GZIP'ed, even if the proper Accept-Encoding header is sent with the request.

The total number of pages returned from a search request decreases as you page through the results. To optimize search results, grouping of similar items is not done until the items are viewed. When the items are viewed and the grouping occurs, the page count shrinks.

Relevancy score values are sometimes unexpected. Relevancy scores are, in part, determined by the number of occurrences of a word. This algorithm can sometimes lead to unexpected results. For example, while you might expect "laptop" to be most relevant to Computers category, the relevancy score is higher in "Sporting Goods" because the word "laptop" occurs there more often, for example, in phrases such as "laptop bag."

ItemSearch sometimes returns an inappropriate Search Index. The Search Index returned is sometimes inappropriate for the ASIN. For example, searching for "Dell Laptops," returns with a Search Index of "Video Games."

In cart operations, validation is not performed on ListItemId. Validation is not performed in some cart operations. It is possible, for example, for the ListItemId not to correspond to the ASIN.

MerchantId does not always filter search results. MerchantId is not used in books, music, classical, video, wireless, DVD, communities, wishlists, Target, and all international stores. MerchantId cannot be used as a filter for any of these groups. Doing so might lead to unexpected results, such as items being sold by some merchant other than the one specified by the MerchantId.

SellerLookup sometimes does not return the Seller Name or correct Location. Results from the SellerLookup operation may not return the SellerName element or return the correct Location values.

ItemLookup does not return some editorial reviews. ItemLookup only returns the editorial reviews written by

Feature elements are missing from ItemAttributes. ECS 4.0 does not return the Feature element, which is returned by ECS 3.0, for ItemAttributes.

Relevance rank and search indexes are incorrect for the Blended search index. The relevance rank and product search index is not correct in ItemSearch results when searches are based on the Blended search index.

Items returned using the PCHardware search index may not be hardware. Using the PCHardware search index with the ItemSearch operation returns non-hardware items.

ItemSearch using Power does not return results as expected for exact dates. The results from the ItemSearch operation may not be correct when using exact dates with the Power parameter. Using date ranges returns expected results.

WishList is returned even when ListType=WeddingRegistry. In ListLookup, when you set ListType to “WeddingRegistry,” the operation returns both a WeddingRegistry and, unexpectedly, a WishList. Both lists are based on the same ListId. When you set ListType to “WishList,” ListLookup only returns a WishList, which is correct.

Customer Reviews not in-sync with the website. Customer Reviews returned by search operations may not be in-sync with the website reviews.

ReleaseDate not returned for some items. Some items, such as DVDs, do not have release dates. Sorting by release date, then, sometimes generates spurious results.

Parent ASINs are not clearly labeled as such. Parent ASINs (items that have variations) are not clearly labeled as such. Currently, you must request the VariationSummary response group to determine whether or not an item is a parent ASIN.

ListLookup response for WishList missing elements for UK, DE. In the UK (, DE (, JP (, FR ( and CA ( locales, a WishList lookup is missing the DateCreated and CustomerName elements. Also, for each Item node in the WishList, the ListitemId, DateAdded, QuantityDesired, QuantityReceived, Seller, and OfferAttributes elements do not appear. Under the OfferListing node, the OfferListingId and ExchangeId elements are missing.

CE ASINs with variations are not returning a list of valid merchants. CE ASINs with variations are not returning a list of valid merchants using ItemLookup.

ISPU items are not accessible via AWS Cart methods. When inserting the ISPU items into the remote cart via OfferListingId, the cart rejects the item with the 'not accessible' error.

Quoted phrase searching is not working in ItemSearch with Keywords. Quoted phrases in the Keywords field for ItemSearch are not accepted as a whole phrase. Instead, they are broken up into individual terms and results are returned for subsets of the phrase. For example, the parameter Keywords="the last time" should only return results for "the last time", rather than "the", "last" or "time".

SimilarityLookup for two ASINs that returns no results does not return an error. The SimilarityLookup operation does not return a NoSimilarities error when no intersecting similarities are found for multiple products that do have similarities. The NoSimilarities error is correctly returned either when the SimilarityLookup request is for one ASIN that has no similarities or when the SimilarityRequest is for two ASINs, only one of which has similarities.

Default input content encoding is not UTF-8. The default input content encoding for ECS 4.0 is ISO-8859-1. The default content input encoding should be UTF-8.

ItemSearch using TextStream may not work for all search indexes. All SearchIndex values are not available to ItemSearch on TextStream, which includes stores like Tools, Software, and Jewelry.

Related Documents

©2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.