App architecture to avoid Spotify Web API rate penalizing

[spapi25]

We are developing an app with the Web API, and have a basic architecture problem. We do understand 429-RetryAfter-backoff. That part is fine.

But even if we handle HTTP 429's correctly, our major concern is that our users will all be coming from different IP addresses. How can we stop accidentally triggering the 12 hour or 24 hour block if we have a normal spike in user traffic from many users at once? Are developers expected to proxy Spotify API calls through our own central server to control rate better (that doesn't seem right)?

My hope -- will Spotify be forgiving of traffic spikes as long as the (potentially very many) user browsers calling from different IP addresses each follow the 429-backoff independently? Or will it penalize us if a bunch of our users happen to hit the API at the same time?

Can anyone share the actual rolling 30 second rate limit number? We are basically doing searches for tracks as a user types.

The 429 backoff doesn't scare us, it's fine, however the 12 or 24 hour lockout we have seen other API users report would be a huge problem.

[LambertSpot]

If you are looking to bring other user's onto your application, you should look at the "Apply for extended quota mode" (found on this page). The development mode is for development, and requires manually adding each user via the dashboard.