I. Calculating Request Quota
a. Request Throttling
Throttling limits are calculated using a leaky bucket algorithm. The amount of available requests at any moment varies based on the restore/recovery rate. In order to receive the maximum amount of throughput applications should not make requests faster than the restore rate.
For an example please see our documentation:
b. Item Throttling
In addition to request throttling, some operations in the Products API also take the number of queried items into account when calculating the remaining request pool. The item-request pool is calculated the same as the request pool. If either of these limits are breached the request will be denied with a 503 (throttled) status response. If your requests include the maximum amount of items, the item throttling limit will likely be reached before the request throttling limit. In order to make efficient use of the request quota while ensuring availability for one-off requests we recommend establishing a request plan for each API operation an application uses. When creating these plans, users should take the operation’s throttling limit, item prioritization (which product’s data are mostly likely to change), marketplaces, item count, and request count into consideration.
c. Feeds Throttling
The submit feed operations allows for a maximum of 30 requests to be made per hour. In order to effectively use the allotted request pool the following should be taken into account:
Feeds should be submitted no more than once every two minutes
Feed submissions of the same FeedType and marketplaceId should be batched together, whenever possible, instead of making multiple feed submissions. We recommend working backwards to establish a SubmitFeed request cadence to ensure regular submissions go through while leaving room to submit feeds for order fulfillment etc.
II. Throttling Enforcement and Third Party applications
a. SellerId – DeveloperId pairs
When registering for MWS, among the credentials sellers receive are their sellerId and developerId. When making MWS API requests with these credentials, request throttling is enforced based on the sellerId – developerId pair. When a seller authorizes a third-party application (or developer), requests made by the third-party will have the seller’s sellerId and the third-party’s developerId. This means a seller using a desktop application (making requests with the seller’s own credentials) while also using an authorized third-party application would have two distinct request pools.
*For Feeds and Reports, though each authorized developer can make requests to these services with separate throttling buckets, all the feed and report queues behind these services are the same for the seller. Feed/Report throughput and processing speed is will be unchanged.
b. Improperly authorized applications
Third party applications that use the seller’s credentials directly (secret key etc) to access MWS, as opposed to being authorized, are forced to share request quota. These applications are much more likely to have request throttling issues as they do not have their own request pools.
c. Request Report throttling
Certain reports have their own report generation throttling limits. These throttling limits are separate from request throttling and appear in a different manner to the end user. When a report generation request is throttled the API request itself will not return a 503 status. Instead the requested report will be cancelled when processed. Report generation throttling is enforced on a sellerId basis.
As report generation throttling is separate from request throttling, the restore rate for the RequestReport operation has no connection to how frequently a particular report can be generated.
To find out if a particular report has limits on how frequently it can be generated please refer to the following documentation: http://docs.developer.amazonservices.com/en_US/reports/Reports_ReportType.html62
III. Logging best practices
Applications making requests to MWS should log all calls made to the service. At a minimum, these logs should have the following information:
Request timestamp with seconds information
Number of items in request (for Products API requests)
MarketplaceId – if applicable (mostly useful for feed submission logs)
An identifier to determine the application making the request
Note: Users that have developed multiple applications that use the same credentials should pool