Amazon Ads API Rate Limits Explained (And How to Stop Hitting Them)

The Amazon Ads API throttles with a token bucket, per endpoint — not one global limit for your whole app. Each endpoint has a bucket with a maximum capacity and a steady refill rate. Every request spends a token; when the bucket is empty, you get:

HTTP 429 Too Many Requests

Because buckets are per-endpoint in this model, hammering the reports endpoint won't throttle your campaign-read calls, and vice versa. This matters: the fix is rarely "request a higher limit" — it's spreading and pacing requests so no single bucket runs dry.

When you get a 429, the response tells you what to do. Respect the Retry-After header — it's the number of seconds to wait before trying again. Blindly retrying without reading it is how a small blip becomes a throttle spiral.

• Retry-After — wait at least this long before re-sending.
• Non-2xx bodies often include a descriptive code; log them so you can tell a 429 (rate) from a 403 (permissions) from a 400 (bad request).

The classic failure: catch a 429, retry immediately in a tight loop. Now you're draining the bucket faster than it refills, and if several workers do it at once you get a thundering herd. Use exponential backoff with jitter:

delay = min(base * 2 ** attempt, max_delay)
delay = delay * (0.5 + random())   # jitter avoids synchronized retries
sleep(delay)

Honor Retry-After when present, and cap attempts so a persistently failing call fails loudly instead of looping forever.

The v3 reporting endpoints are asynchronous: you request a report, then poll for completion, then download. The throttle magnet is the polling step — teams poll every second and drain the bucket. Poll with backoff (e.g., 10s, then 20s, then 30s), not in a tight loop, and download once the status is complete.

The durable fix is architectural, not more retries:

• Cache what doesn't change — profile IDs, portfolio lists, campaign metadata. Don't re-fetch them every run.
• Request only the data you need — narrower report types and date ranges cost fewer calls.
• Spread jobs over time — stagger multi-account pulls instead of firing them all at the top of the hour.
• Use Marketing Stream for hourly metrics — instead of polling reports every hour, let Amazon push hourly data to you. It sidesteps the reporting buckets entirely.

Is the Ads API rate limit per app or per endpoint?

Amazon doesn't publish it either way. Its rate-limiting page says limits are dynamic and based on system load, and that report limits depend on the size of the regional report queue. In practice, throttling on one operation hasn't throttled the others in my integrations, so pace each hot endpoint independently and always obey Retry-After.

What should I do when I get a 429?

Read the Retry-After header and wait that long, then retry with exponential backoff and jitter. Never retry immediately in a loop.

Can I ask Amazon to raise my rate limit?

Sometimes, but it's rarely the real fix. Most throttling comes from bursty requests or tight polling loops. Smooth your traffic first; a limit increase is a last resort.

Does Marketing Stream have the same limits?

No — Marketing Stream is push-based. Amazon delivers hourly data into your AWS, so you're not polling and not consuming reporting-endpoint tokens at all.

Do the same limits apply through the Ads MCP server?

Yes. MCP is a access layer over the same API, so the throttling behaves identically — and an agent fanning out across tools can hit it faster than a person clicking through a console. See connecting Claude to Amazon Ads MCP for how that surface is put together.