Amazon Product API Rate Limits: the 429 TooManyRequests Fix

Quick answer: A 429 from Amazon's Creators API means you crossed one of two separate ceilings,
transactions per second or transactions per day. Amazon sizes both from your shipped item revenue over the
previous 30 days and re-allocates them daily, so more traffic does not buy you more requests. The fastest wins
are batching up to 10 ASINs into one GetItems call, spreading requests over all 24 hours, and
caching inside Amazon's published TTLs.
Your Amazon product grids were fine this morning. By mid-afternoon half of them are empty, the WordPress error log has filled up, and every line says the same thing.
That is Amazon's throttle. It is not a bug in your plugin and it is not your host. Refreshing the page will not clear it either. Your site is asking Amazon for product data faster than your account is currently allowed to ask, so Amazon has started dropping the surplus.
The confusing part is that the same account worked yesterday. Amazon's product API rate limits are not a fixed number you can look up once and design around. They are recalculated every day, from an input most affiliates never think to check.
Your request quota comes from shipped revenue, not traffic
Every new integration starts in the same place. Amazon's API rates documentation grants a fresh Creators API credential a maximum of one request per second and a cumulative 8,640 requests per day for the first 30 days. That is a starter allowance meant for building and testing, not for running a busy catalog.
After that, the allowance is recalculated from your sales. Your account earns one TPD for every five cents of shipped item revenue generated through Creators API links in the previous 30 days, and one TPS for every $4,320 of that revenue, up to a ceiling of ten TPS. The allocation updates daily. Amazon publishes those dollar figures in USD on every locale's copy of the page, so a UK or Indian affiliate reads the same $4,320.
Shipped revenue, not commission. Amazon defines it as the total sales volume of all items it has shipped from orders resulting from clicks through links you created with the API. The unit is dollars of product sold, so a site selling a few expensive items can earn more quota than a site selling many cheap ones at the same commission.
Pageviews and sessions are nowhere in that formula. A traffic spike gives you more visitors hammering your search box and exactly zero extra requests to serve them with. Traffic appears in Amazon's documentation only as something that consumes quota.
The 10 sales rule is a different mechanism
This is where most write-ups get it wrong. The revenue formula above sets your rate. The qualifying-sales bar is a separate on or off gate on whether you hold API access at all. Amazon's Creators API introduction states the condition plainly: you need at least 10 qualifying sales within the past 30 days to hold Creators API access, and the same threshold is repeated in the machine-readable reason code your plugin will see if you fall under it.
Two mechanisms, two failure modes. Cross the rate and you get a 429. Fall through the gate and you get a 403, which looks nothing like a throttle in your logs and everything like one in your product grids.
The chicken and egg problem. You need sales to hold API access, and the API is how most affiliate sites display products in the first place. Amazon's own answer is that if you lose Creators API access you can keep using other linking tools such as Site Stripe and keep generating revenue, and that access returns within two days after your referred sales are shipped. That is a real constraint on the whole category, not something a plugin can engineer away.
TPS and TPD throttle independently
TPS caps how many calls you can make in any single second. TPD caps how many you can make across the whole day. Fixing your per-second pacing does not protect you from the daily counter, and Amazon spells that out in its own definition:
"TPD ... refers to the maximum number of API calls you can make in one day. If Associate has 1 TPS and 8640 TPD, then maximum of 1 request can be sent per second and 8640 per day. Even if 1 TPS is there, once TPD is exhausted requests will be throttled."
Amazon, Creators API rates documentationRun the arithmetic on the starting floor and the practical shape of the limit shows up. A day holds 86,400 seconds. An 8,640 request budget spread evenly across it is one call every ten seconds, sustained, all day. A WordPress site that fires a burst of uncached searches every time a visitor lands can burn a day of that in an afternoon and then sit dark until the counter resets.
That is also why Amazon's best practices page asks for even pacing rather than bursts. Consistent traffic sent over all 24 hours maximizes the number of calls you can make in a day, and Amazon notes the pacing has to be controlled down to the second, because anything above your TPS inside any given second gets throttled.
429, 403 and 403: telling three identical failures apart
From the reader's chair, all three look the same: the products stop loading. In the logs they are completely different problems with completely different fixes. Amazon's error code reference is the place to match what you actually received.
| What you see | What it is | What to do |
|---|---|---|
429 ThrottleException |
A real rate limit. You crossed TPS or TPD. | Back off and retry with exponential backoff. Then cut your request count using the list below. |
403 AssociateNotEligible |
The eligibility gate, not a rate limit. The account does not meet the qualifying-sales requirement. | Nothing in your code will clear this. It clears when qualifying sales ship. |
403 AccessDeniedException with a deprecation message |
The call went to PA-API 5, which Amazon has deprecated in favor of the Creators API. | Move the integration to the Creators API. Old credentials do not carry over. |
401 UnauthorizedException |
Missing or bad authentication for the operation. | Check the OAuth credentials and the token, not the request volume. |
400 InvalidPartnerTag |
The partner tag is invalid or is not mapped to the store tied to your credential. | Fix the Associate tag in settings. No commissions are tracked until you do. |
500 InternalServerException |
Amazon's side, not yours. | Retry with exponential backoff. |
200 with an errors array |
A partial success. Some ASINs resolved, some did not. | Read the array. If every item is invalid you get a 404 instead, with no partial response. |
On retry timing. Amazon documents the wait as an optional retryAfterSeconds field
inside the JSON error body, and it says the response may include it. Exponential backoff is the
documented baseline. Code that waits for a value that might not arrive will stall.
What Amazon's product API rate limits mean for a WordPress site
Everything above is throughput. The practical question is how a WordPress site spends fewer transactions per visitor. Amazon's best practices page answers most of it directly, and the highest-leverage item is the one people skip.
Seven ways to cut your request count
GetItems call accepts up to 10 item IDs and Amazon
counts the whole call as a single transaction. Ten separate one-ASIN calls cost ten transactions. One
batched call covering the same ten products costs one.
Offers and
BrowseNodeInfo at one hour, and everything else at one day. Check the cache before you call,
and call only for what is missing.
One sizing detail worth knowing before you plan pagination: SearchItems accepts an item count between
1 and 10 and a page number between 1 and 10. That puts the hard ceiling at 100 results, and each page you fetch is
its own transaction.
One more, for anyone porting old code. Price and availability on the Creators API come from
OffersV2. A snippet that asks for Offers.Listings is PA-API v5 code and will not work
here. If that is where your integration is stuck, the Creators API
troubleshooting guide walks the authentication errors, and the Creators API comparison covers what changed
between the two.
Why "cache harder" is the advice to be careful with
Caching is the correct fix for throttling. It is also where a throttling post can walk a reader straight into a breach of the Associates Program agreement, because the caching rules are not only in the developer docs. They are in the Associates Program IP License, and the license attaches a condition to slow refreshes that almost nobody writes about.
Clause 2(h) sets the ceiling. Non-image product advertising content may be cached for up to 24 hours, after which a refresh call is required. Images are treated differently: the clause forbids storing or caching image content and permits storing only a link to it, also for up to 24 hours. ASINs are exempt and may be stored indefinitely until the license terminates.
Read that images line twice. The developer TTL table lists Images in the one-day row, which
reads like permission to cache the picture. The Images resource returns URLs. Pulling Amazon product
images down into the WordPress media library is a different act from caching a link, and clause 2(h) addresses it
directly.
Then comes clause 2(i), which is the one that matters for anyone tempted to set a long TTL on prices. It ties a display obligation to refresh frequency:
"(i) You will include a date/time stamp adjacent to your display of pricing or availability information on your application if you obtain Product Advertising Content from Data Feeds, or if you call Creators API, PA API or refresh the Product Advertising Content displayed on your application less frequently than hourly."
Associates Program IP License, clause 2(i)The same clause requires a specific disclaimer beside the price or reachable from it through a link, pop-up or similar method. Amazon's wording, quoted rather than summarized because the exact sentence is the point:
"Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on [relevant Amazon Site(s), as applicable] at the time of purchase will apply to the purchase of this product."
Associates Program IP License, clause 2(i)Set those two documents side by side and the line is easy to see. Amazon's developer docs put the recommended TTL
for Offers, the price and availability resource, at one hour. Clause 2(i) draws its threshold at
refreshing less frequently than hourly. Both documents land on the same hour. Cache prices at or under it and
clause 2(i) does not engage at all. Go past it and the timestamp and the disclaimer come with the decision.
Those are Amazon's rules as written, linked above so you can read the clauses in full rather than take a blog post's word for them. How they apply to any particular site is a question for that site's owner.
Where this leaves a plugin
PaapiPlugin caches search results for 30 minutes and individual
product data for one hour. Both sit at or under the one-hour TTL Amazon recommends for Offers. The
practical effect is that repeat visitors to the same category page are served from cache rather than from your
daily transaction budget, and price data on the page is never more than an hour from Amazon.
Caching is the part of the quota problem a plugin can actually solve for you. The rest of the list above is architecture: batching, pacing, resource selection, token reuse and backoff all live in whatever code talks to Amazon. It is worth knowing which of those your current setup does before you go looking for a bigger allowance you cannot buy.
Rate limit questions affiliates ask
What does a 429 TooManyRequests error from the Creators API mean?
It means your request was denied by Amazon's throttle. The exception type in the response body is
ThrottleException and the HTTP status text is "Too Many Requests". You crossed either your
transactions-per-second ceiling or your transactions-per-day ceiling. Amazon's documented remediation is
exponential backoff and retry, and the response body may include a retryAfterSeconds field with a
suggested wait.
How does Amazon decide how many API requests I get?
By shipped item revenue over the previous 30 days. A new credential starts at one TPS and 8,640 TPD for its first 30 days. After that, Amazon grants one TPD for every five cents of shipped item revenue generated through Creators API links, and one TPS for every $4,320 of that revenue, capped at ten TPS. The allocation is updated daily.
Is the 10 qualifying sales rule the same thing as the request quota?
No, and conflating them is the common mistake. Shipped revenue sets the rate you are allowed to call at. The
qualifying-sales requirement, at least 10 in the past 30 days, is a separate eligibility gate on whether you hold
API access at all. Crossing the rate returns a 429. Failing the gate returns a 403 with the
AssociateNotEligible reason code.
Can I fix throttling by caching Amazon prices for 24 hours?
The 24-hour figure is the IP License ceiling for caching non-image content, not Amazon's guidance for prices.
Amazon's developer documentation puts the recommended TTL for the Offers resource, which carries price
and availability, at one hour. Separately, clause 2(i) of the IP License attaches a date/time stamp requirement
and a specific disclaimer to refreshing pricing or availability less frequently than hourly. Read both before
setting a long TTL on prices.
How many ASINs can I request in one GetItems call?
Up to 10, and the whole call counts as a single transaction against your quota. Amazon states it in its own
definition of TPS: sending 10 ASINs in the request parameter of a GetItems call counts as one
transaction. For any integration looping one ASIN at a time, batching is a straight tenfold gain in throughput.
Why am I getting a 403 instead of a 429?
A 403 is not a rate limit. Two common causes look identical from the front end. AssociateNotEligible
means the account does not meet the qualifying-sales requirement for Creators API access. An
AccessDeniedException carrying a deprecation message means the request went to PA-API 5, which Amazon
has deprecated in favor of the Creators API. Neither is fixed by slowing down.
What happens to my API access if I stop making sales?
Amazon's api-rates page states that an account loses Creators API access if it has not generated qualified referring sales for a consecutive 30-day period. That is worded differently from Amazon's introduction page, which puts the bar at 10 qualifying sales in the trailing 30 days, and Amazon does not reconcile the two anywhere. Either way, other linking tools such as Site Stripe keep working and keep generating revenue in the meantime, and Amazon says access returns within two days after your referred sales are shipped.
Spend fewer requests per visitor
PaapiPlugin puts live Amazon search, category browsing and product displays on your WordPress site, with search results cached for 30 minutes and product data for one hour so repeat views do not spend a transaction. Free on WordPress.org.
See the full feature list →

