Amazon's Selling Partner API powers every third-party tool. But between rate limits, throttling, and burst quotas, most developers spend more time fighting the API than building features. This guide covers everything you need to know.
Dec 4, 2025 · 14 min · 3,200 words
Refreshed for 2026
Amazon's Selling Partner API (SP-API) powers every third-party analytics tool, repricing software, and inventory management system. But between rate limits, throttling, and burst quotas, most developers spend more time fighting the API than building features. This guide covers everything you need to know about SP-API rate limits in 2026.
If you've ever seen "Request too frequent" errors or watched your data pipeline grind to a halt, you understand the frustration. The SP-API isn't just one API. It's 20+ different endpoints, each with its own rate limit rules, authentication requirements, and quirks that Amazon rarely documents clearly.
We've spent years building data pipelines that handle hundreds of Amazon seller accounts. This guide shares everything we've learned about rate limits, throttling strategies, and why most DIY pipelines eventually fail. If you're evaluating whether to build your own pipeline or use a service like Nova's ready-made data delivery, this will help you make an informed decision.
Rate limits control how many API requests you can make in a given time period. Amazon uses rate limits to protect their systems from overload and ensure fair access for all developers. When you exceed these limits, you get throttled (your requests fail until you slow down).
The sustained rate at which you can make requests. Most endpoints allow 1-5 requests per second.
The maximum requests you can make in a short burst. Allows temporary spikes above the sustained rate.
How quickly your quota refills after being depleted. Typically measured in requests per second.
Some endpoints have additional daily limits, regardless of how slowly you make requests.
Rate limits vary by seller tier, marketplace, time of day, and endpoint. A limit that works fine for a small seller might throttle constantly for a large brand. Amazon also changes limits without warning, breaking pipelines overnight.
Here's a comprehensive breakdown of rate limits for the most commonly used SP-API endpoints. These are based on Amazon's official documentation and our real-world experience.
| Endpoint | Rate (RPS) | Burst | Notes |
|---|---|---|---|
| Orders API | 0.0167 | 20 | 1 request per minute sustained |
| Reports API | 0.0222 | 10 | Report generation is async |
| Catalog Items | 5 | 40 | Relatively generous |
| Inventory API | 2 | 30 | FBA inventory updates |
| Finances API | 0.5 | 30 | Financial events & settlements |
| FBA Inbound | 2 | 30 | Shipment management |
| Notifications API | 1 | 5 | Subscription management |
| Product Pricing | 0.5 | 1 | Very restrictive |
| Advertising API | Varies | Varies | Separate from SP-API |
Instead of making thousands of individual API calls to the Orders endpoint, request a report. One report can contain all your orders for a time period, drastically reducing API calls. The tradeoff is latency (reports take minutes to generate).
Nova delivers clean, analysis-ready Amazon data to your warehouse hourly. No rate limits to manage, no throttling to debug, no schema changes to chase.
When you hit rate limits, Amazon returns a 429 (Too Many Requests) error. Your code needs to handle this gracefully. Here are the strategies we use:
Queue all API requests and process them at a controlled rate. This is essential when managing multiple seller accounts.
If you're building for an agency or aggregator with 50+ accounts, each account has its own rate limits. You need 50 separate token buckets, 50 queues, and logic to prioritize which accounts get refreshed first. This is where DIY pipelines become unmanageable.
"We spent 8 months building our own SP-API pipeline. By month 4, we had working data. By month 8, we realized maintenance was eating 40% of one engineer's time. Switching to Nova was the best decision we made."
We've talked to dozens of teams who tried to build their own SP-API pipelines. Here's what typically goes wrong:
Teams estimate 2-3 months. The reality is 12-18 months for a complete pipeline. Rate limit handling alone takes weeks to get right.
Amazon changes field names, adds new fee types, and deprecates endpoints quarterly. Each change requires engineering time to fix.
The Orders API doesn't match the Reports API which doesn't match Settlement Reports. Figuring out which source is "correct" takes months.
Even after launch, plan for 0.5-1 full-time engineer just to keep the pipeline running. That's $100K+/year in perpetuity.
$300K-$500K
6-18 months development
$100K+
0.5-1 FTE dedicated
24-48 hrs
Full historical backfill
We've solved these problems for 500+ brands. Stop wrestling with APIs and get clean, query-ready data delivered to your stack.
Our ready-made Amazon raw data service abstracts away all the complexity of SP-API rate limits. Here's what we do behind the scenes:
We optimize request timing across all accounts to maximize throughput while staying under limits.
When throttled, we automatically back off and retry. You never see the failures.
We use bulk reports instead of individual API calls wherever possible, reducing total requests by 99%.
Despite all the rate limit complexity, we deliver fresh data to your warehouse every hour.
Clean, normalized data: 200+ report types merged into unified schemas
Pre-calculated KPIs: 369 metrics ready to query
Historical backfills: 2+ years of historical data included
Multi-marketplace: US, UK, DE, FR, and more in one dataset
BigQuery or Snowflake: Data delivered to your warehouse
If you're evaluating how to get Amazon data into your analytics stack, you have three options:
If you have 12+ months of engineering time, dedicated data engineers, and budget for ongoing maintenance. Good for unique requirements that no service can meet.
Get data in your warehouse in 24-48 hours. We handle rate limits, schema changes, and maintenance. Best for teams that want to focus on analysis, not infrastructure. Learn more →
Download CSV exports manually. Works for small sellers with simple needs. Doesn't scale and data is always 24-48 hours stale.
Related reading: How to Get Amazon Seller Data into BigQuery | Snowflake Guide
Get normalized Amazon data delivered to your warehouse in days, not months. 360+ metrics, hourly refresh, zero maintenance.
Explore more expert insights to grow your Amazon business
Your data team already uses Snowflake. Getting Amazon seller data in shouldn't require 18 months of engineering. Learn 3 paths: DIY SP-API, ETL tools, or Nova's pre-built Snowflake delivery with hourly refresh.
Building an Amazon data pipeline from scratch takes 18+ months and costs $2M+ in engineering time. Learn three paths to getting Amazon seller data into BigQuery: DIY with SP-API, ETL tools like Airbyte, or pre-built solutions. Includes SQL query examples for P&L analysis.
Build an enterprise data warehouse for multi-marketplace analytics. Compare BigQuery vs Snowflake, handle the 20-30% API data gaps, and implement cost-effective data infrastructure.
