Inquiry About API Quota Extension Requirements

[hectoorperezz]

Plan

Premium

Country

Spain

My Question or Issue

Hello Spotify team,

My name is Hector, and my team and I have been working for four months on a music discovery tool for Spotify users. During this time, we’ve invested significant effort in:

Designing an intuitive interface to help users uncover new artists and genres.

Implementing secure authentication flows that keep users in control of their data.

Testing and optimizing various Web API endpoints to deliver real-time, personalized recommendations.

We believe our app will add real value to the Spotify ecosystem by helping listeners connect with music they might never find otherwise. However, the current 25-user limit in Developer

Mode is making it very difficult to:

Validate the experience with a broader test group

Stress-test performance and edge cases

Prepare for a controlled, phased launch

Could you please advise whether there is any path for early-stage projects like ours to meet the new quota-extension criteria? Any guidance on how we might demonstrate responsible usage or intermediate steps we can take before reaching the high-MAU thresholds would be extremely helpful.

Thank you for your time and support. We look forward to any recommendations you can share.

Best regards,

[ribezaz]

Welcome to the Spotify Community, it's great to have you here! 😊

Thanks for sharing this very detailed behavior — it really helps those who are also developing with the Web API!

The snapshot_id should indeed reflect changes in the playlist content, and it is expected to change whenever a track is added, removed, or reordered. However, as you noted, there may be a slight delay in updating the snapshot_id after modifications, especially in collaborative or highly active playlists.

This delay is usually related to internal caching and synchronization mechanisms on Spotify's servers. The API may return the new playlist content before the new snapshot_id is fully propagated.

If snapshot consistency is critical to your bot, you may want to use a verification system based on local hashes of the tracks (e.g. IDs and order) as a fallback.

For actions such as updating or modifying the playlist, it is always recommended to wait a few seconds after the change before reusing the snapshot_id, ensuring that it has already been updated.

Continue using polling with appropriate spacing (every 30s to 1min, for example) to avoid rate limits.

I hope this helps you understand this behavior better!

If you want to exchange more ideas about architecture or optimization strategies for bots, I'm available.

Keep me updated

Cheers,
ribezaz 💚🎧

[hectoorperezz]

Thank you for the detailed explanation around snapshot_id updates and the caching behavior—this will definitely help us build a more reliable fallback when working with collaborative playlists.

I did want to ask about another constraint we’re running into: the 25-user limit in Developer Mode is proving to be a major bottleneck for us. Even with reasonable spacing between API calls, we simply can’t validate our discovery workflows or scale our testing beyond a handful of friends.

Would it be possible to request an increase in the maximum number of users who can authorize our app, even if our existing rate-limit thresholds remain unchanged? Having a slightly larger test audience would allow us to iron out UX issues and ensure that when we launch publicly, we’re providing a smooth, stable experience for Spotify users.

Thanks again for your support—any guidance you can share on expanding that user cap would be greatly appreciated!

[ribezaz]

I believe that, in this case, it would be better for you to contact support, they will be able to inform you better in this case 🙂