What rate am I actually allowed?

It depends on the operation, and it is not a single published number you can hard-code. Read x-amzn-RateLimit-Limit from the response, which reports the rate applying to that call. Amazon also adjusts some limits dynamically based on usage, so a value that was right last quarter may not be right now. Treat the header as the source of truth rather than documentation you copied once.

Is sleeping between calls wrong?

It is not wrong, it is just crude. A fixed sleep has to be tuned to the slowest endpoint you call, so every faster endpoint runs far below its allowance. It works and it is a reasonable first response to a production problem. It stops being reasonable when you are still doing it a year later and your nightly sync takes six hours.

Why does it happen more after an outage?

Because a backlog invites you to catch up quickly, which is exactly when you exceed the burst allowance. The correct behaviour is counter-intuitive: after an interruption, drain the backlog more slowly than normal, not faster. Racing produces throttling, which produces a bigger backlog.

Can retries make it worse?

Yes. Each retry is a request against the same budget. Retrying immediately on QuotaExceeded keeps you at the limit indefinitely. Back off exponentially with jitter, and if several workers share credentials, make sure they share a limiter too, or they will retry in lockstep and recreate the spike.

How would you build it?

With a per-operation token bucket fed by the rate headers, so each endpoint runs near its own allowance instead of everything running at the pace of the slowest. Requests queue rather than fail, backlogs drain at a deliberate rate, and writes carry idempotency so a retry cannot duplicate a shipment confirmation or a feed submission.

QuotaExceeded - Amazon SP-API - seamless.engineering

QuotaExceeded

In short

QuotaExceeded means you have exceeded the rate limit for the operation you called. The important detail is that SP-API limits are per operation, not one global budget: orders, reports, listings and finance endpoints each have their own rate and burst, so an integration can be comfortably within budget on one call and throttled on the next. The response carries x-amzn-RateLimit-Limit with the rate that applies. Sleeping between calls works and is what most people do first, but it paces to the slowest endpoint and wastes most of the available throughput.

What the error means

QuotaExceeded is Amazon’s throttling response on the Selling Partner API. Your credentials are valid, the request was acceptable, and you have called this operation too often for the rate you are allowed.

The response includes x-amzn-RateLimit-Limit, reporting the rate that applies to the operation you just called.

The detail that changes how you build

Limits are per operation, not per application.

This is the difference between an integration that works and one that spends its life throttled. There is no single budget you can pace against. Getting orders, requesting reports, updating listings and pulling financial events each have their own rate and burst allowance, and they differ by an order of magnitude in places.

Two consequences follow:

A single global sleep tuned to the tightest endpoint wastes most of your available throughput everywhere else.
An integration can be nowhere near its limit on one call and throttled on the very next one, which makes the behaviour look random when it is not.

Amazon also adjusts some limits based on usage over time, so a number that was accurate when the integration was written may not be accurate now. Anything hard-coded from documentation will drift.

The catch-up trap

The most common way to make this worse is to respond to a backlog by going faster.

After an outage, an expired authorisation or a failed overnight run, there is a queue of work and an obvious temptation to clear it quickly. That is precisely the pattern that exhausts the burst allowance, triggers throttling, and leaves you with a larger backlog than you started with.

The correct response is to drain a backlog more slowly than the steady state, not faster. It feels wrong and it is right.

Handling it properly

Practice	Why
Read `x-amzn-RateLimit-Limit` from responses	The applicable rate, from the authority, right now
Keep a token bucket per operation	Each endpoint runs near its own allowance
Exponential backoff with jitter	Stops parallel workers retrying in lockstep
One shared limiter across all workers	Otherwise concurrency silently multiplies your rate
Idempotency on writes	A retried feed or confirmation must not apply twice
Throttle backlog drain below steady state	Catching up fast is how you stay throttled

Why this is an operations concern

SP-API is not a stable target. Amazon adds operations, deprecates others, moves functionality between report types and adjusts limits. An integration paced correctly at build time will drift out of correctness without anyone touching it.

We pace per operation, from the response headers, so throughput follows the actual allowance rather than a number someone read once.
Throttling is expected and instrumented. We alert on work not completing within its window, not on the presence of throttling, because the second one is normal and the first one costs you money.
Backlogs drain deliberately. After any interruption, catch-up runs at a controlled rate with progress visible, rather than racing and re-throttling.
We track SP-API changes daily. Deprecations and limit changes arrive as planned work instead of as a sync that quietly stopped delivering orders.

Frequently asked questions

What rate am I actually allowed?: It depends on the operation, and it is not a single published number you can hard-code. Read x-amzn-RateLimit-Limit from the response, which reports the rate applying to that call. Amazon also adjusts some limits dynamically based on usage, so a value that was right last quarter may not be right now. Treat the header as the source of truth rather than documentation you copied once.
Is sleeping between calls wrong?: It is not wrong, it is just crude. A fixed sleep has to be tuned to the slowest endpoint you call, so every faster endpoint runs far below its allowance. It works and it is a reasonable first response to a production problem. It stops being reasonable when you are still doing it a year later and your nightly sync takes six hours.
Why does it happen more after an outage?: Because a backlog invites you to catch up quickly, which is exactly when you exceed the burst allowance. The correct behaviour is counter-intuitive: after an interruption, drain the backlog more slowly than normal, not faster. Racing produces throttling, which produces a bigger backlog.
Can retries make it worse?: Yes. Each retry is a request against the same budget. Retrying immediately on QuotaExceeded keeps you at the limit indefinitely. Back off exponentially with jitter, and if several workers share credentials, make sure they share a limiter too, or they will retry in lockstep and recreate the spike.
How would you build it?: With a per-operation token bucket fed by the rate headers, so each endpoint runs near its own allowance instead of everything running at the pace of the slowest. Requests queue rather than fail, backlogs drain at a deliberate rate, and writes carry idempotency so a retry cannot duplicate a shipment confirmation or a feed submission.

// scoping request

Seeing this in production and want it to stop being your problem? We design, build, and permanently operate the pipeline, including the validation and retry logic that stops this class of failure reaching you. Fixed-price scoping quote within 48 hours.