Updating the Criteria for Web API Extended Access

[ThePodfather]

Hey, I created this thread to get your feedback on our blog post around changes to the Web API extended access criteria, which will take place on May 15th.

Please share any of your thoughts on this change in the comments below. All of your feedback will be reviewed and compiled so I can share directly with the S4D team.

Whilst I won’t be replying to individual pieces of feedback in this thread, please know that everything shared here will be read and considered. Any related threads or questions posted elsewhere on this topic will be merged here so everything is in one place.

Thanks for taking the time to share your thoughts.

Update:

• Sharing some clarification that developers with existing quota moda extensions will keep their extension if they are actively using the Web API and remain in compliance with our Developer Terms. This update only applies to new developers in Dev mode seeking extended access
• As outlined in our blog post, if you've submitted your application before May 15th, we are committing to reviewing your submission based on prior criteria, whether you hear from us before that date or not.
• The criteria for the new process can be found HERE.

[zhiyin]

Dear Spotify Team,
 I hope this message finds you well.
  As a long-time Spotify user, I’ve always admired how your platform has transformed the way people experience music — especially in the car. For many of us, Spotify is more than just an app; it’s part of the driving experience. That’s why I’m currently developing OttoDriveLink, an open-source automotive interface designed to help bring Spotify into a wider range of vehicles in a lightweight, secure, and privacy-respecting way.
My goal with OttoDriveLink is to enable drivers — whether they're in a brand-new EV or a decade-old sedan — to access Spotify safely and intuitively while on the road. The project is built around four core values:

• Accessibility: Lightweight enough to run even on low-end hardware
• Driver Safety: UI designed with distraction-minimizing principles
• Privacy-Focused: No data collection or tracking, only opt-in interactions
• Community-Oriented: Open source and welcoming contributions from developers

  While reviewing the Spotify Developer Policy, I believe my project aligns well with its guidelines. However, I encountered a major challenge when trying to gain API access: the new quota requirements make it extremely difficult — if not impossible — for small-scale or independent developers like myself to move forward.
Specifically, the current criteria include:

• Needing an officially registered business entity
• Operating a fully launched service
• Having at least 250,000 monthly active users
• Being available in key Spotify markets

  For early-stage projects like mine, these thresholds are simply out of reach. Going from prototype to 250k MAUs before even being allowed to scale API usage is unrealistic. It creates a "catch-22" where you can’t grow without access, but you can’t get access without already having grown.
Spotify has always been seen as a platform that empowers creators and innovators. I hope it won’t become one that only supports large companies or well-funded startups. Many meaningful improvements to user experience come from individual builders and niche communities — especially in verticals like automotive integration, where flexibility and deep understanding of context matter more than scale.
  If this door is closed now, promising tools like OttoDriveLink — which could extend Spotify’s reach into underrepresented vehicle environments — may never have the chance to prove their value.
Therefore, I’d like to suggest considering alternative paths for smaller, experimental, but purpose-driven integrations — such as a sandbox environment or tiered quota system tailored for indie developers and early-stage projects. This would not only foster innovation but also help Spotify grow into more diverse use cases and platforms.
Thank you for your time and consideration.
Warm regards, Developer of OttoDriveLink

[Wael9993]

I was building spotivibez.com, how am I supposed to get 250k users for it, if the app is unusable?

[lukens]

You may have struggled with that under previously existing rules around having a name too similar to Spotify.

”You agree not to attempt to use or register any trademark or domain name that includes the word “Spotify,” any other Spotify trademark, or any name that is confusingly similar to any of them.”

[joelemoure]

So if we want users to be able to "Continue with Spotify" in our small app we either need to allow list them first (up to 25), or have 250k MAU? How would it ever be possible for a small app ever get from 25 specific allowed users to 250k?

[joelemoure]

Quota modes | Spotify for Developers

Quota Extension Request for New Potential Partners

Please note that as of May 15th 2025, Spotify only accepts applications only from organizations (not individuals). For more information on this update, read here.

Application must be sent through a company email by using this form. Check out the implementation requirements below to make sure your company is compatible before submitting your application.

Implementation requirements:

1. Established Business Entity (legally registered business or organisation)
2. Operating an active, and Launched Service
3. Maintaining a minimum of active users (at least 250k MAUs)
4. Being available in key Spotify markets
5. Commercial Viability
6. Adherence to Terms

[simonmares]

tl;dr I'm disappointed at this evasive messaging. I wish you would pick the harder, more glorious path and block the bad actors instead of shutting down the API for almost all developers.

---

Dear Spotify,

As my only love brand, I'm so, so disappointed at your corporately evasive messaging. First, "Introducing some changes to our Web API", where you clearly wanted to avoid misusing the API for AI development but hid behind "more secure platform", and now you're saying "only a small portion of developers (less than 1%) should be impacted", but you're effectively shutting down the developer API for the public (probably just because of costs) without explicitly saying so.

From a customer perspective, you were—and still are—probably my only love brand. We all know the story: you broke the industry and rebuilt it so subscription-based access to all music is the baseline. Many companies now offer similar services, but you're still distinguished by music recommendation and all the implemented ideas and details in the apps. But with your latest posts, you just became one of these corporates. It's so black and white. I just tried to read these announcements from another perspective than Spotify.

As a developer, I was happy to find an open API that was not perfect but quite usable and used it to develop an app that would show the Spotify library in a new, refreshing way and let any (!) number of music superfans use it too. It felt great as it combined my music fanship with software development craftsmanship. I always accepted the risk of developing integration with a third party, and I will try my chances with the competition, which has some technical benefits. However, I would always pick you if I had the option.

I understand that development, running, and maintenance of the API were and are costly, and there is no real super-success application that would bring millions of users to Spotify. But there are many integrations (like Raycast) and mini apps that make Spotify easier or more fun to control, and this ecosystem is what contributes to the love brand of Spotify. I wish you would rather block bad actors and let creativity flow—do the harder but right thing.

Regarding API costs, I understand that many apps weren't using the API most efficiently, and new vibe-coded apps might be even worse at this. But there are ways to handle it, like those suggested in the super long post  before me.

[Ogi23]

As others replying here before me, I find it hard to believe that "only a small portion of developers (less than 1%) should be impacted". These changes effectively ban any independent developers and most start ups from developing apps with Spotify API. There must a better way to handle this without stifling creativity while ensuring security and standards are in place!

I am heartbroken to have spent months developing an app for people to browse and export their record collections in Spotify just to find that I can only share it with friends and family in the end. I envisage my app to attract 1000s of users and to be extremely useful to a decently sized community but it won't get anywhere close to 250k MAUs (especially if I can't get past 25 allow listed users in the first place). I imagine the same will apply to thousands of other apps that could be built creatively and evolve into good partnerships and attract more users to Spotify but won't because of these changes. 

While I don't deny the need to maintain security standards and to manage resources effectively, it would be great to see Spotify support the developer community e.g. by at least revising development mode restrictions to allow more active users by default, without having to manually add them first. This way smaller, but meaningful projects would stand a chance of taking off at all.

[Choheron]

I hold the same concerns as the rest of the thread here. I am deeply discouraged to see these changes effectively eliminating all small developers' ability to start a project and prepare for it to grow using the Spotify API. These quota restrictions and criteria changes seem like a thinly veiled way to eliminate growth of smaller groups that could eventually contribute to the overall improvement and marketability of Spotify. Limiting developers to a maximum of manually added users for testing and then requiring a monthly user count of 250k is disorienting at the least. I was under the impression it was a typo when I first read over the new criteria. I sincerely hope the Spotify team can rethink some of these changes, or perhaps offer a quota mode in the interim that allows for smaller applications to have a larger set of options/quotas, without full extended quota? 

Spotify always seemed like a phenomenal platform for new developers, and this feels like a slap in the face for developers looking to create something new and interesting. 

[luis1997]

Hello. I hope you can enable the API in the future, even if it comes at a price, at least so we can finish the projects we've already started. Thanks for reading.

[user-removed]

If you believe in your App... there are other API's available that are FREE and you can build. Reuse your design and idea! I already moved on and my plans are in full motion! Too bad Spotify - your loss!

[snaplist]

Hello ThePodfather, 

The Snaplist Development team is both perplexed and devastated by the recent changes to the extended quota mode approval requirements. We have developed a passion project into a scalable, revenue generating and uniquely innovative companion app for Spotify with full publication to the iOS and Android app stores. The new criteria requiring 250K MAUs (Monthly Active Users) is only sustainable for existing platforms who integrate Spotify into an existing popular service and consequently quashes all original development by restricting API access only to whitelisted developer accounts for apps without extended quota mode. 

This poses an insurmountable barrier for original developers as they cannot gain any new users unless already supporting the 250K MAUs as a prerequisite. Without providing an on-ramp for developers, Spotify has effectively declared persona non-grata on original development. Given Spotify's excellent track record with supporting innovation and development, this seems more of an unintentional consequence rather than a deliberate policy change. Additional clarity regarding the future of the Spotify Developer Program would be much appreciated. 

The Snaplist Team understands that Spotify needs to protect against intellectual property theft, data mining and misuse of their APIs, and fully supports any measures that Spotify takes to protect their brand and assets in the ever-evolving digital landscape. However, the team urges Spotify to reconsider adding a new intermediary mode to facilitate production-ready, published applications to at least function with external (non-whitelisted) accounts, albeit with a restricted API usage limits. 

Once again, the Snaplist Team cannot overstate how devastating the implementation of these changes have been. Our mission has been (and is) to upgrade the listening experience of Spotify users with exciting and innovating ways to produce the perfect playlists by shifting the time and effort burden of researching and compiling playlists away from users to Snaplist. Our mission has been (and is) to innovate in the music space, a value we associated strongly with Spotify. Over the years, Spotify has launched many innovative and exciting features, creating a brand of excellence and innovation which excited developers. 

We do not want to develop for Amazon Music or Tencent or Tidal. Spotify has been integral to our lives since its inception both as clients (users) and innovators (developers). While it would not be much work to port Snaplist to support other streaming services, the Snaplist Team would really prefer to develop on the best platform, striving for the ultimate user experience. 

In summary, please reconsider either modifying the prerequisite of 250K MAUs for extended quota mode applicants or the creation of a new mode which permits non-whitelisted Spotify users to enjoy Spotify content via originally developed apps. 

With deep gratitude and concern, 

The Snaplist Team

Snaplist @ iOS App Store
Snaplist @ Google Play Store

[snaplist]

The Snaplist Development team concurs. The bridge from 25 whitelisted users to 250K MAUs is entirely unattainable. We propose an intermediary mode which permits the full (or broader) API availability than Development mode but with tighter usage limits than Extended Quota Mode. 

This would revive all currently 'dead' projects and provide an on-ramp to success under the new framework. 

[snaplist]

The Snaplist team agrees. Spotify is our love brand. We chose Spotify not because of market dominance but because it's our home. We are intimately integrated with Spotify beyond what could be considered standard for clients of a service. We join your voice in urging Spotify to revise the implementation of the new policies not simply as disappointed developers but as disheartened fans. 

[snaplist]

The Snaplist Development team echoes this sentiment. An intermediary (temporary) quota mode is a sound proposal, or even a pricing scheme for API usage would ease the concerns from small developers with Big-Tech sized aspirations. 

[snaplist]

The Snaplist Development Team is eager for a response to this topic. Snaplist was submitted prior to the May 15 deadline and was rejected, we believe, due to a likely misunderstanding in our data handling process, which we hope to clarify in the hopes of an approval for Extended Quota Mode under the previous framework. 

[snaplist]

This would be funny if we weren't so heartbroken

[Riss2025]

Is there an appeals process once the request for extension quota has been denied?

[jjmunky]

Dear Spotify Developer Team,

I'm writing as an independent developer who has spent significant time building a personal music analytics application that helps users understand their listening patterns and discover new music. My application, while not a commercial product, provides meaningful value to music enthusiasts by:

1. Implementing secure authentication using PKCE for enhanced security

2. Creating detailed visualizations of listening trends and genre evolution

3. Providing personalized music discovery features

4. Following best practices for data management and user privacy

I understand the need to manage API resources effectively, but I'm concerned that the new criteria for extended access will effectively prevent independent developers like myself from sharing our tools with the broader community. My application:

- Uses the Web API responsibly with proper rate limiting

- Implements efficient caching strategies to minimize API calls

- Focuses on enhancing the Spotify experience for music enthusiasts

- Follows all security and privacy best practices

The new criteria seem to prioritize commercial partnerships and established applications, which could stifle innovation from the independent developer community. Many of the most creative and useful Spotify integrations have come from independent developers who identified unique use cases that larger companies might overlook.

I would respectfully suggest:

1. Creating a middle tier for non-commercial applications that demonstrate responsible API usage

2. Establishing clear metrics for what constitutes "impactful" use cases

3. Providing a path for independent developers to demonstrate their application's value

4. Considering a graduated quota system based on actual usage patterns

I believe there's room for both commercial partnerships and independent innovation in the Spotify ecosystem. The current changes risk losing valuable contributions from the developer community that has helped make Spotify's platform so vibrant.

[postinferno]

bruh devs got ratioed again

[copystrike]

250k MAU is an unrealistic requirement for small developers and startups.

This policy effectively blocks indie developers and early-stage companies from responsibly growing on the platform. Expecting 250,000 monthly active users before granting access to extended quota is counterproductive and discouraging.

Please reconsider this decision. It stifles innovation and punishes passionate teams who are trying to build valuable and compliant experiences for Spotify users.