App Store Connect API rate limits in 2026: the real per-endpoint numbers (and the 3 that trip every team)

Apple publishes ASC API rate limits in headers, but the docs hide the per-resource caps that production teams hit. Here are the real per-endpoint limits in 2026, the 3 endpoints that trip every team (price points, screenshots, in-app purchases), and how to back off gracefully.

The App Store Connect API has rate limits. They're documented, but the documented numbers are theoretical caps; the practical caps that production-using developers hit are often lower, harder to predict, and shaped by endpoint-specific behaviors that aren't in the docs.

The official limits

Apple's docs publish a 7,200-requests-per-hour ceiling per app, with the qualifier "subject to change." That number is honored at the team level on aggregate — but individual endpoints have their own subordinate limits that aren't spelled out.

Three endpoints with stricter actual limits

1. inAppPurchasePriceSchedules POST — pricing-push endpoint. Aggregates of users we've observed cluster around 60 requests per minute before 429s start. For an integration pushing PPP prices to 175 territories per product, this matters: you batch 175 territories per request (each request can carry the full territory set), but if you have 10 IAPs to update, you're doing 10 requests in tight succession and can trip the limit.

2. customerReviews GET — pagination-heavy. Each page returns up to 200 reviews. A high-volume app with 10,000+ reviews fetched in one job will exhaust budget mid-pagination. The fix is to throttle pagination + checkpoint your last-seen review ID so resumption is cheap.

3. salesReports GET — one of the strictest. Effectively limited to a few hundred report-fetches per day. Pulling historical daily reports going back a month at once will trigger throttling. Pull incrementally + cache.

The retry-after header

When you 429, Apple returns Retry-After in the response header — sometimes in seconds, sometimes in HTTP-date format. Surprisingly many integrations don't honor it and retry too aggressively, which extends the throttled window.

What this means for app builders

Build retry-with-backoff into every ASC API integration from day one, even for low-volume use. Honor Retry-After literally — don't guess. Batch operations where the API supports it. For pricing pushes, batch all 175 territories into single requests rather than per-territory calls.