28

The spotify web API documentation mentions rate limits. For example, the authorization guide says this:

Only endpoints that do not access user information can be accessed. Its advantage is that a higher rate limit is applied compared with requests to the Web API made without an access token.

Are rate limits something I, as a developer, need to worry about? Will requests to the web API fail if I exceed my rate limit, and if so, what would the failure look like?

cigien
  • 57,834
  • 11
  • 73
  • 112
Larry Person
  • 321
  • 1
  • 5
  • 8

1 Answers1

34

You'll find some general information about rate limiting in the User Guide. As described under Status codes, the Web API will return HTTP status code 429 (Too Many Requests) if your application makes more requests than the rate limit allowed.

If this happens, you should wait a while (see update below) before making requests again. Of course, the best thing to do is to try to avoid reaching the rate limit in the first place. As the User guide suggests, you can do this by for example accessing multiple entities at once which is available for some endpoints. You could also cache responses.

Update: If you're rate limited, the HTTP response will include a header named 'Retry-After'. The value of this header is the amount of seconds you need to wait until making the next request. For example, Retry-After: 4 means that you need to wait four seconds before trying again. This is now also mentioned in the Web API User Guide.

Community
  • 1
  • 1
Michael Thelin
  • 4,710
  • 3
  • 23
  • 29
  • 3
    I don't find that that is the case. Usually I get a 500 error when I make too many requests too fast... – Goodword Feb 29 '16 at 02:50
  • That shouldn't be the case and could be a sign of a bug. It'd be interesting to know what endpoints you're calling. We do have a known issue in the Playlist related endpoints. – Michael Thelin Feb 29 '16 at 08:56
  • 14
    It appears that the Retry-After value is calculated from milliseconds, rounded half-down to the nearest second. For example, if Spotify were going to remove the rate limit in 3200MS, you receive a Retry-After header of 3. Running your request again after 3 seconds on the dot will mean that your code could fall foul of the 200MS discrepancy. For this reason you should always +1 to the Retry-After value. – RoryGilchrist Jan 31 '17 at 17:05
  • 3
    @MichaelThelin Is there any number approxx. like n requests per minute – Pradeep Singh Jun 09 '17 at 11:04
  • 5
    The reason why it isn't disclosed is because this number may change without warning. Using Retry-After _should_ be enough to be able to write an application that handles being rate limited. That said, counting on having somewhere around 10-20 requests per second would put you in the correct ballpark. – Michael Thelin Jun 10 '17 at 22:44