JSON_LISTINGS_FEED rate limits should be per account/locale, unviable per account

[nightcoding2021]

Typically sellers are operating multiple locales on a single sellerId/account as opposed to a separate sellerId/account for each locale. Unfortunately JSON_LISTINGS_FEED is limited on a per sellerId/account basis, as opposed to sellerId/locale pair. This means that as locales are added to a sellerId/account, the available file upload capacity is divided by more and more locales. In those regions with more locales than others, such as Europe region with 15, the capacity limitation gets more acute.

The documentation itself states that JSON_LISTINGS_FEED only support a single marketplace at a time. So in the case of, for example, 10 locales on a single sellerId, it would take about an hour just to upload a single file to each locale.

One completely incorrect thinking would be that each locale in a region is homogenous for a given seller. To start with, each locale will have differing tax rates, differing costs of business such as freight or environmental taxes, and a different inventory profile based on sales rights and locale customer demand. The locales have been established at different times, some dating back to the earliest days of Amazon, and others in more recent years. Sellers may have built a locale-focused business in each one to serve the distinct customer base. So, in some cases, each locale could be a distinct stand-alone business.

With regards to the JSON_LISTINGS_FEED rate limits overall, they are too low and has the effect of blocking timely updates. If a seller has received and has ready to offer on-hand inventory for sale, the sooner that is offered for sale on Amazon it will sell. Amazon is competing with numerous other marketplaces, and if multi-hour delays are now introduced then fresh inventory will be made available for sale elsewhere far sooner. In many cases, the inventory will have been offered for sale and sold - before Amazon even has the offer live. Likewise, sellers need to be able to remove inventory promptly to avoid offering for sale out of stock inventory (due to being sold elsewhere). A delay of say a few hours may not sound much - but in the event of sudden demand that can be hundreds of orders per SKU, and aggregated across Amazon's entire business the JSON_LISTINGS_FEED slow down (making inventory generally more stale on Amazon) would probably mean millions of additional cancelled orders on platform.

For the reasons above, based on the available evidence/experience, my view is Amazon should urgently update the limits to be per SellerId/locale pair, and not just sellerId, which appears to be completely unviable.

[ritikacd]

Hi @nightcoding2021

Thank you for sharing your challenges and insights. We want to inform you that we are actively looking to optimize rate limits for the JSON_LISTINGS_FEED to enhance the developer experience. We will share an update once it's available.

To stay informed about updates, we recommend:

• Monitoring our developer documentation announcements
• Subscribing to our RSS feed for immediate notifications

For critical inventory updates, we recommend using patchListingsItems to prevent potential overselling or underselling issues.

Thanks,
Ritika
Selling Partner API Developer Services

[nightcoding2021]

Regarding the announcement of higher rate limits, this is welcome but does nothing to address the discrepancy of rate limits per region. The per-region limits unfairly restrict updates to those regions with more locales than others, for example Europe region could be up to 15 active locales (which can be expected to increase further over time). This may sound academic, however, the real world impact is severe delays to inventory management/updates on those regions (namely Europe) which has more locales.

Sure Amazon can proceed "as is", however it will slow new inventory being offered for sale, slow removing unavailable inventory, largely block any price updates due to limited processing capacity, which all combined worsens the Amazon customer experience. Slower updates negatively affect seller metrics so make it more likely sellers would be deactivated. Amazon should also consider that there's competition, and if it isn't even possible to offer inventory for sale on Amazon without it taking many hours: some will already have been listed and sold out on alternative venues.

Also, how are the actual processing limits working? The documentation states all the file upload does is pass the contents to SP API. I believe the problem I'm seeing is again the limits are set per region - this makes management extremely difficut for primarily the Europe region. Right now I've got files that haven't entered processing that were uploaded 6 hours ago. They will do so but are in a queue on the Amazon system.

I believe Amazon needs to realize they are making a mistake, and set the file and processing limits per locale instead of per region. In the meantime, please consider postponing (or ideally cancelling altogether) the proposed 30 June switch off.

On the patchListingsItems suggestion, the overall framework is too complicated and long established to do some updates as API calls and some as file uploads. This has already involved looking at infrastructure/processes dating back over 20 years, for absolutely zero benefit, with the overall determined impact currently deemed as guaranteed negative.