Overview of usage plans and rate limits

This blog provides overview of usage plans and rate limits and best practices for managing resources.

by Olivia S., Solutions Architect, Selling Partner Developer Services | April 25, 2023

API reliability depends on sizing your capacity and resources to meet the changing needs of applications over time. To do this, you must understand and forecast usage, then manage the frequency of requests to protect against overwhelming the service at peak usage times.

This blog post helps you discover the resources available for understanding usage plans and rate limits, and provides pointers and best practices. For further information, refer to Usage Plans and Rate Limits in Selling Partner API (SP-API).

About usage plans and rate limits

Learn about the components of a usage plan and different usage plan types.

Usage plan definitions

Each usage plan consists of a rate and burst, defined as follows:

  • Rate: The number of requests per second that are added to the token bucket and can be used to submit requests without experiencing throttling. If you are making calls continuously over a long period of time, staying below this rate will help you avoid throttled requests.
  • Burst:The maximum size that the token bucket can reach. Over time, you can build the number of requests up to the maximum, then submit them simultaneously.

You can find the rate limits in each API Reference. The following example usage plan table shows the rate limit and burst.

Usage Plan Types

  • Standard Usage Plans: Standard usage plans have rate limits that are static for all callers.
  • Dynamic Usage Plans Dynamic usage plans automatically adjust to each selling partner based on the current and historical business needs for that business.


Dynamic usage plan availability

Dynamic usage plans are only available for the Orders API v0 and the getFeaturedOfferExpectedPriceBatch operation in the Product Pricing API v2022-05-01.

x-amzn-RateLimit-Limit Response Header

The x-amzn-RateLimit-Limit Response Header returns the rate limits for an SP-API operation when you submit a request. Before attempting to use the rate limit value, check for the presence of a header. If the request is unauthorized, unauthenticated, or throttled, the x-amzn-RateLimit-Limit will not return a response.


Troubleshooting authorization errors

Refer to Troubleshooting Selling Partner API authorization errors when the request shows these issues.

Key things to note

Learn interesting facts about usage plans to utilize them to their fullest extent.

Default usage limits are specific to each seller and region

Usage limits for API operations are specific to each seller and region. If you are a developer with more than one seller account, then the usage limits are applicable to each of your seller accounts.


Marketplace regions

A region encompasses multiple marketplaces. For example, the North America region includes the Canada, United States, Mexico, and Brazil marketplaces.

Dynamic usage plans automatically adjust to selling partner needs

A dynamic usage plan is one whose rates automatically adjust to each selling partner according to the usage of the API. The API rates adjust over time based on the current and historical needs for that business.

Rate limiter Implementation

Implementation of the rate limiter is crucial to avoiding bandwidth wastage. As mentioned earlier, the rate limit is specific to each seller, so make sure to implement the rate limiter for every selling partner.

If you receive a 429 error, try incrementally delaying your request by 2 seconds. If you receive consecutive error responses, try implementing an exponential backoff algorithm by progressively increasing wait times between retries. For further guidance on optimizing rate limits, refer to this code snippet from Strategies to optimize rate limits for your application workloads blog post.

We recommend batching together your operations in a group if you have a large number of seller accounts. For example, if you have hundreds of seller accounts, you can batch together your operations in groups of thousands each. You can refer to our Reducing API calls with batch functionality blog post and Batch operations video to learn more about batch operations.

Event-driven architecture to improve performance

To avoid polling, use the Notifications API to build out event-driven architecture. You can learn more about the benefits of creating Notifications for Reports through our blog post on Event-drive architecture and its corresponding video on reports utilization.

Reports and Feeds for bulk data

We have a wide range of report types and feed types available that can help you retrieve or upload bulk data without having to wait to restore available requests. You can also schedule report types and retrieve them at a time of your choosing. To get started, refer to the Report Type Use Case Guide and Feeds API Use Case Guide.


This blog walked you through usage plan and rate limits within SP-API and clarified definitions. It also explained how these usage plans apply to different developers and provided takeaways on how to make the best use of usage plans and rate limits.

For more resources, refer to:
Blog: Strategies to optimize rate limits for your application
Blog: Event-driven architecture in Selling Partner API
Webinar: Optimize Amazon SP-API Call Patterns


Have feedback on this post?

If you have questions or feedback on this post, we'd like to hear from you! Please vote and leave a comment using the tools at the bottom of this page.

Subscribe to updates via RSS feed.