Rate limit scope for Amazon Ads API v1 Reports (beta) — per Client ID or per refresh token?

[SiddharthDedhia]

Hello all,

I'm integrating with the new Amazon Ads API v1 Reports (beta) and I'm trying to understand how rate limits are scoped.

Specifically: are the rate limits enforced at the Client ID level (Amazon-Advertising-API-ClientId header), meaning all API calls I make share a single bucket regardless of which advertiser account they're for — or are they enforced at the refresh token / advertiser account level, meaning each seller/vendor account I manage gets its own independent rate limit quota?

Any documentation, clarification, or example throttle headers from the API response would be really helpful.

Likewise for v3 reporting. I always assumed it was scoped to profile id.

Thank you all in advance !

[everton-dgn]

Looking at the official Rate limiting page, the public docs don't promise a per-Client-ID, per-refresh-token, or per-profile bucket. What they do promise for reporting endpoints is a shared regional bucket tied to the queue size at any given moment:

Rate limits associated with the Sponsored Ads reporting API, Sponsored Display reports API, and the Sponsored Brands reports API depend on the size of the report generation queue. These limits are determined on a per-region basis with multiple limit tiers that correspond to the current reporting queue size in a given region.

Source: https://advertising.amazon.com/API/docs/en-us/reference/concepts/rate-limiting

So v1 Reports (beta) and v3 reporting (/reporting/reports) both sit on that same per-region model in the docs. Your intuition that v3 is scoped to profileId isn't something the official page confirms; nothing there pegs the quota to a profile, a refresh token, or a Client ID. The profile just defines which advertiser's data a call targets, not the throttle bucket.

For non-reporting endpoints the same page stays vague:

Rate limits in the Amazon Ads API are dynamic and based on system load.

Again, no documented scope per Client ID or per profile.

On headers: the only documented throttle signal is the 429 response plus a Retry-After (seconds to wait). Example shape:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

There's no x-amzn-RateLimit-Limit / -Remaining header like SP-API exposes.

Same page also recommends exponential backoff on 429 and 5xx, avoiding list*Extended operations (they carry 5x the throttling weight), and using /exports in place of paginated list when fetching bulk entity data.

Practical implication if you manage many advertisers: adding another seller/vendor refresh token doesn't buy you extra throughput, because the bucket is (as documented) regional and queue-driven. The only public lever is shaping traffic across the day and across regions.

If you want behavior tied to profile or account quota that's not visible in the public docs, opening an issue on this repo asking for explicit clarification would probably be the right path; the docs team does respond here.

[kdwivedi13]

Thank you for raising this — it's exactly the kind of feedback that helps us improve! 🙏

We appreciate you sharing your experience with rate limits, and we'll definitely work on making the documentation clearer on this topic.

A couple of important points I'd like to highlight:

1. Ads Reporting API V1 is still in open beta. We'd advise against running production workloads on it at this stage. We encourage you to explore it, run tests, and share your feedback with us. Once V1 reaches General Availability (GA), it will be fully ready for production use. Please keep an eye on the release notes for updates!

2. Experiencing throttling issues with the V3 Reporting API? We'd love to have a conversation about your specific use case — there may be better alternatives available. For example, have you explored Amazon Marketing Stream? It could be a great fit depending on your needs.

I'd be happy to jump on a quick call to dive deeper, understand your use case, gather your feedback, and offer some tailored suggestions. Feel free to reach out! 😊

[siddharthdedhiaheadln]

Hey @kdwivedi13 is the amazon reporting API v1 yet in beta? What is the rate limit I can expect on the v1 reporting API currently?

A rough estimate for e.g. 15 reports per hour with 5 accounts and date range 1 day , or something similar would be a really helpful metric for me to decide to switch to the new API for production use.

Thank you so much once again

[siddharthdedhiaheadln]

Thank you for the resposnes @kdwivedi13 @everton-dgn

Sorry for the late reply

[matthieuauger]

Hi @kdwivedi13 — chiming in as a different developer with a closely related use case (not the original poster, hope it's OK to add to the thread). Thanks for the answer, and @everton-dgn for the per-region / queue-based detail. Understood that v1 Reports is open beta and not production-ready yet; we're evaluating it for when it reaches GA.

Context: we run an analytics platform for Amazon sellers who connect their Advertising accounts to our app. We store a refresh token and pull data on their behalf ~3x/day. Today we use v3 for Sponsored Products and Display, and v2 for Sponsored Brands (Sponsored Brands Video doesn't seem supported on v3).

v1 is appealing to us for three reasons:

• it would sharply cut our call volume (v2 needs one call per day for the daily-by-ASIN breakdown);
• it unifies the field schema across ad types;
• it offers ~15 months of backfill history instead of ~60 days.

Empirically, on v2/v3 throttling seems to scale per seller (per refresh token), which fits us well and scales horizontally. On v1 we get throttled in ways we can't explain — on a subset of ~500 sellers, about half hit 429s.

Two questions:

1. Is v1 reporting throttling currently scoped to the Client ID only (driven by regional load), rather than per advertiser/refresh token the way it behaves for us on v2/v3?
2. Is v1's throttling expected to be consistent with v2/v3 at GA, or intentionally different?

On Amazon Marketing Stream: it looks great for live data, but we also need historical backfill, which is exactly where the Reports API is essential for us — so Stream feels complementary rather than a replacement. Happy to be corrected if there's a backfill path we're missing.

I'd also gladly take the call you offered, but I couldn't find a direct way to reach you (LinkedIn DMs are paywalled). Is there an email or scheduling link I could use? Thanks!