iTunes search rate limited? 403 Forbidden errors

Thank you for the update.

If there is a new rate limiting algorithm being deployed, I hope it take into consideration that the iTunes Search API is not only used by affiliates on the web but also by Apple Music iOS API users.

The iTunes search API is often the only way to get the "store ids" that are needed in the Apple Music API of the iOS SDK.

If an IP based access/rate limit is used, it means that the misbeahavior of an iOS app could led to other apps being impacted by the limit.

In my case the requests are made from an iOS app. The 403s starts to appear after about 25 requests from the same IP.

Aggressive caching in the iOS app would not help because after about 25 requests, searches starts to fail (with 403) even if the search terms have not been used before on the requesting IP.

My search terms are usually made of full track names with limit=15.

I was also getting these 403 responses from the iTunes Search API recently but it seems to have stopped now.

However I am currently getting a data caching issue that I have posted about here:

https://forums.developer.apple.com/thread/67484

Not sure if this is something new or just something that I haven't noticed before.

We are having this issue as well. Filed Radar 29208232 in case that helps

How do we look up the issue using that ID?

We as well are still having this issue. Anyone have any new updates from Apple?

Hey All,

I filed a bug report and they replied saying this is a duplicate of bug ID 29055870. However, there's no way to check the status of that bug ID because you cannot view the status of someone else's bug report. Apple uses duplicate bug reports as a measure of priority, so our best bet would be to for all of us to file a bug report so something gets done. Aside from that, maybe if we tweet at someone from Apple, they'll be able to tell us the bug status.

I'm still experiencing the issue, seems worse than before even.

Some reqeusts are being served, but the majority are now returning 403's.

I'm sure it's a rate limiting issue as when I make the exact same request on my PC, it returns 200 with results rather than the 403 on our production server.

I have also logged this as 29274733

Please, please also log it so that this gets some priority with Apple. The more people that mention it and report it, the earlier it will get fixed.

You can log it here : https://bugreport.apple.com

Thanks all.

Hi omega1,

What product did you report it under? I reported to "iTunes" as well as "other" but neither of those seemed exactly right

Hi markhoudini

I also struggling to know where to log it, so I logged it under iTunes. Not logged a bug with Apple yet, so not sure how long it may take for them to acknowledge/respond...

If anyone finds this thread and has the same issue, please log a bug with them at the address above and if anyone gets a response, please kindly feedback here!

Thanks.

Seems to be general policy now:

https://affiliate.itunes.apple.com/resources/documentation/itunes-enterprise-partner-feed/

is saying

"The iTunes Search API is currently limited to approximately 20 calls per minute (subject to change)."

Which seems to be about right, when I set the delay to 3 seconds (~20 calls/minute) it works fine. Reducing down to 2 seconds (~30 calls/minute) causes 403 errors.

So in case you need more, the only option seems to be to apply for the Enterprise Partner Feed and maintain the DB yourself.

Yes, I've just had the same response from Apple.

20 Search API calls per minute.

I'm applying for the Enterprise Feed and will make searches to a local database as 20 per minute is nowhere near enough for my requirements, I have started to cache the small amount of results I'm getting, but started doing it too late and do not have enough searches stored, so looks liek the only way for me at the moment to resolve...

Thank you all for comments and feedback, I gess just needed that confirmation as to what the limits were and now we have it.

After about 1000 requests at the new rate, 403s are back.

Hm.. Well... I think it was due to a bug in my rate limiting algorithm.