Web API ratelimit

[lemonpill]

I am developing an app which will allow users to publish their playlists to a feed. However in order to visit the feed, published playlists will have to be fetched one by one (as the current spotify api does not have an endpoint to fetch multiple playlists at once).

In order to optimize the application feed, I would like to know, which rate limit currently applies on /playlists/{id} for authorized users.

[Hubo]

Hey @lemonpill, help's here!

Good question — you can find more information about rate limits and the Web API here: https://developer.spotify.com/documentation/web-api/guides/rate-limits/. Let me know if you have any questions! 🙂

Have a great day,
Hubo

[lemonpill]

Unfortunately, I could not find a reference to a number of requests allowed
for an app to make to /playlists/{id} in Ratelimits section. Please assist.

[Hubo · Accepted solution]

Thanks for getting back to me!

I'm afraid there are currently no absolute numbers to share about this. Spotify’s API rate limit is calculated based on the number of calls that your app makes to Spotify in a rolling 30 second window. If you reach the rate limit and get errors, I recommend requesting a quota extension in your Spotify for Developers Dashboard and/or implementing one of the techniques featured on the page I mentioned before. 🙂

Let me know if you still need a hand!

Have a great day,
Hubo

[arsnl]

---

@Hubo wrote:

Spotify’s API rate limit is calculated based on the number of calls that your app makes to Spotify in a rolling 30 second window. If you reach the rate limit and get errors

---

Without saying what is the value of "the rate limit", that answer have no value. 😕

Does anyone know, or experienced, what is "the rate limit" (eg: number of call per 30 seconds your App can make). It's really strange to have such a hard time to find this value. This kind of information is kinda really important to display publicly.

[wireframed]

Its because they want to have the option of adjusting it to load so the value might vary over time of day and month. 

They’ve previously indicated if you aim for a max of 20 requests per second or so, you should be within a reasonable window. 

But to be clear that is not a firmly communicated value, just something they at the time felt wouldn’t cause issues. 

[arsnl]

I just found this article on medium.
https://medium.com/mendix/limiting-your-amount-of-calls-in-mendix-most-of-the-time-rest-835dde55b10e....

The Spotify API service has a dynamic rate limit based on the number of calls within a rolling 30 second timeframe. Based on testing, we found that Spotify allows for approximately 180 requests per minute without returning the error 429. 

Look's like 180 is the value we are looking for.

[arsnl]

Thanks for the clarification @wireframed! 🙂 Sad they don't display this information directly in their developer's documentation. "Request for a quota extension" sounds like a last resort solution and it's hard to tell if someone need to request one if you don't know what are the limits.

[wireframed]

Glad to be of help. Just keep in mind Spotify explicitly doesn’t guarantee any rate. I assume they don’t want to encourage unhealthy dev practices like assuming your application can make a certain number of requests in a timeframe when that might change without warning. 

Hence the consistent official response of “there is no fixed rate limit, but check the header response and design your app to gracefully back off”. 

But I understand the frustration - I faced the same when designing my app, and had no idea if polling play status was acceptable every second, or every 5 or 10. Sure your code should handle the 429 response but it’s still useful to know if your basic design will cause constant 429 errors since you might as well redesign it then. 

[transcapybara]

It would be helpful if Spotify Engineering gives extra headers on each response as to how to tune to the rate limiting correctly. If done right, each call would give a response header that contained when the next API call can be made for the endpoint that was just used. Design it in a way where engineers can use those headers and never experience a 429 response, except in worse case scenario cases. An excellent example of this is the Discord API rate limiting headers documented at https://discord.com/developers/docs/topics/rate-limits

[ricrichardthomas1]

Also, apart from the rolling 30 second rate limit it would be really helpful to understand if there is a per-day rate limit for specific request types. Apart from saying that other rate limits may be enforced, spotify has not explicitly stated if there's a per-day rate limit or not in the documentation. It needn't be an absolute number, but atleast if the existance of a dynamic daily rate limit similar to the 30 second rolling limit is confimed, it would make a lot of sense to me why my requests to fetch artist albums hangs despite making sure that I'm sleeping for 1 sec after every request made. It seems to do the trick for fetching artist details but not for artist albums for some wierd reason.

[Tsamsi]

I just tryed it i get  a couple errors when i thry to use 3 request per second. i tryed it with about 30 requests. 2 of them went into an error. when your application can handle this then it shouldnt be a problem. if not try 2.5 requests a second and you''ll be fine.

[wireframed]

Please be aware that there isn't a fixed limit, so you can easily encounter a situation where 2 requests per second is NOT fine.

The only correct way is to use a back-off principle and handle the 429 response correctly by implementing a wait-time equal to the value in the "Retry-After" header.

Obviously a sane starting point is necessary, but handling the 429 message correctly, is critical.

[redorchestra]

certain endpoints have a 24 hour window for determining rate limits, i'm pretty sure. if you make more than 200 requests to the recommendations endpoint within a 24 hour window for example, you get a 24 hour timeout on your entire application for that endpoint it seems, based on the bit of testing i've done. other endpoints do work with the 30s rolling window, but certainly not all. the more intensive the underlying calculations are for every call to the api, or the greater the value of the data you could mine with those endpoints, the stricter the rate limit i think. that does make sense to a certain extent, but it doesn't really showcase much in the way of transparency on spotify's end, as it's not written anywhere in the documentation as far as i can tell. the 24 hour window also seems to apply to the audio-features/analysis endpoints, but i'm not entirely sure about that yet.

[palmers97]

I’ve found that the audio-features endpoint does still work when I’m rate limited from the recommendations endpoint. Weirdly enough, the get genre seeds endpoint does not work (weird because it doesn’t seem costly or dangerous to have this virtually unguarded). I agree strongly spotify should make it public there exists a 24 hour limit window. It seemed like that’s what was going on, but without any info in the docs, I began to doubt myself and debug code that is otherwise fine. It would’ve been nice to have confirmation other than your comment (but THANK YOU for being here to make me not feel so crazy lol)