According to the appstoreconnect json api docs, rates are supposed to be limited to a certain number of requests per hour (in my case it seems to be 3600) Doc here: https://developer.apple.com/documentation/appstoreconnectapi/identifying_rate_limits
However, in my usage, I'm getting HTTP 429 RATE_LIMIT_EXCEEDED, while at the same time getting a header back indicating that there are plenty of requests left this hour (e.g. "x-rate-limit": "user-hour-lim:3600;user-hour-rem:3121;").
I'll handle these responses gracefully, and retry them later of course, but we have a lot of iaps to keep up to date, so I'd really like to be able to optimize my request rate so that I don't wind up making a bunch of requests over and over again in hopes of getting them to go through.
Is it possible that there's some secret rate limit for parallelized requests? I've got my updater running in multiple threads in hopes of making the whole process faster, and started by sending them as quick as I could up to the specified limit per hour. In most cases we've only got a few dozen / hundred iaps to update at a time, but I also need it to work in the rare instances when we need to update thousands at once.
I'm also tracking data locally so that I only need to post updates when prices actually change, but sometimes we do put everything on sale.
Aha! I finally figured it out. In case anybody else runs into this problem, here's what I found:
It would seem that after 300-350 requests in a given clock minute I'd start getting 429s, until quickly every request was a 429. When the clock ticked over to the next minute, then the 429s would go away until I got to the next 300-350. Limiting to only 300 requests in a given clock minute has entirely solved the problem.
So, on top of the documented limit on requests per hour, there seems to be a quiet limit on requests per minute. I imagine the 300 number is not set in stone, so user beware, but that's how I got it fix.