Changes to Web API

[Loneliest_Cabin]

Folks, some news on changes to the web API has been posted on the Spotify For Developers blog.

We want to reiterate the main message from the blog that we're committed to providing a safe and secure environment for all Spotify stakeholders. As such we have recently made some important changes related to access to some of our endpoints and functionality. You can read the details on the blog: https://developer.spotify.com/blog/2024-11-27-changes-to-the-web-api

We are here to listen to any feedback you may have. 

[jmpeters]

Hi, to any developers affected, my name is Jay Peters, I'm a reporter with The Verge  -- I'd be interested in talking more about any response to these changes, could you email me? My email is in my author profile: https://www.theverge.com/authors/jay-peters
-Jay

[domienf]

You essentially ruined a fun none proffit game i was working on. Thanks spotify

[SadMastersStudent]

This has completely derailed my masters project, which relied heavily on the audio features endpoint. I have no clue what to do now.

[jdevenegas]

Bunch of corporate cowards that don't want anyone to build new tools and products on top of their tools. If it is greed (of course it is), then at least allow developers to pay a premium to access these endpoints. This makes Spotify look absolutely pathetic. 

[404Developer404]

This really sucks

[thesystemera]

I'm seriously considering making one, open sourcing the code and having a system designed where multiple parties can have it run in the background and submit to the unified database. Just spent some time last night getting the basics and was able to extract many of the audio features required, in my case, audio dB readings, so my DJs know when to speak, aka the end of a track. Have designed it to grab from multiple sources and essentially extract analytics and then purge initial data. Grabs the lowest resolution tracks, so is rather bandwidth effective and everything is based on ISRC, so identification should be accurate. Though because of the size of the data required, this is definately going to have to be a group effort, just to avoid rate-limiting etc. Can't believe its had to come to this. Was at the final stages of my project. A full blown Radio experience. PLAiR Personalized Localized Adaptive Interactive Radio. And I'm not ready to quit yet, we have major interest from well established icons in the music and film industry, investors. And not ready for this to die. I was already looking at migrating the code to other streaming services anyhow and so we need an alternative to audio features and analytics anyway, and its a gap in the market. FU Spotify! But yeah, once I get the basic code going, and get some servers up. Will look at githubing the code for the greater community. A little demotivated at the moment as one can imagine. Was literally meant to demo this to Shaquille O'neal this week, so am just mentally exhausted.

[DouglasAdams]

@thesystemera - What you describe already exists as a community project that's well established with lots of existing data, I guess I can't DM you on this forum (it seems disabled). Would rather not share on Spfy's own blog, but you can find it pretty easily by asking ChatGPT

[thesystemera]

I'm well aware of musicbrainz and the acousticbrainz one, though that got closed a few years back, and I haven't found anything that does dB levels. Gosh, if I'm completely missing something here, please feel free to elaborate. You can email me at simon at realityvirtual.co - likely do myself and the rest of the community a big favour, I could be super missing the forest from the trees here. 

[thesystemera]

Have emailed you Jay. Love your credentials too. I use to be heavily involved in VR space years back, did Nefertari: Journey to Eternity some years back! Bit of a jack of all trades over here 🙂

[djmacy]

I’m seeking some clarification regarding the recent deprecation of the Audio Features endpoints in the Spotify API and the impact it has on apps with an "unreviewed" extension request. Specifically, I’m trying to understand the following:

1. Will these endpoints (Audio Features) be permanently unavailable to apps, even those that will eventually get an approved extension request or are launched in production?

   I noticed that my app is still in development mode, and while I understand the need for compliance with the TOS, I’m trying to figure out if the endpoints are now off-limits forever, or if there’s still a chance to regain access once my app transitions to production. For example, will these endpoints become accessible again if the extension request is eventually approved?

2. What exactly constitutes a "pending" extension request?

   My current status is listed as "unreviewed," with a decision still undecided. I’m curious if this status is the reason I currently don’t have access to these endpoints. Are apps in "unreviewed" status automatically blocked from using the deprecated endpoints until the request is reviewed and approved?

It’s been a bit stressful trying to navigate these changes, especially after rushing this weekend to comply with the terms of service and get my web app online. I’m hoping there’s a way to clarify if my app will still be able to use these features once my extension request is reviewed. From what I can tell, other apps that are not in development seem to still have access, which suggests the endpoints are still in use. The article posted was fairly vague and sudden, so any clarification would be greatly appreciated.

[0x5700]

Dear Spotify Developer Team,

Thank you for sharing the recent updates regarding the changes to the Web API on the Spotify for Developers blog. I truly appreciate Spotify's ongoing commitment to maintaining a safe and secure environment for all stakeholders.

As a dedicated user of the Spotify API, I highly value the opportunities it provides to create engaging and innovative experiences for users. I am fully aligned with your vision and would love to continue leveraging your API services to enhance my application.

Additionally, I am eager to have my extension application reviewed and approved, as it aligns with Spotify’s standards for security and user experience. Please let me know if there is any additional information or steps required on my end to support this process.

Thank you again for your efforts in fostering a collaborative developer ecosystem. I look forward to contributing further to the Spotify community.

[jerboa88]

Like others here, I had to find out about these changes by Googling why my project broke all of a sudden.

I understand that scraping is an problem and that giving notice may have given offenders a window to abuse the system, but this is probably the worse possible way to address the issue.

I'm sure developers could have find a way to work with rate limits, allow listing, and/or alternative endpoints, but dressing the announcement as a safety and security issue and not giving developers any advance notice is soulless and a sure way to kill developer trust.

To me, the actual API changes are almost a secondary issue at this point. That being said, I had a small project for archiving Discover Weekly and Release Radar playlists every week and it is pretty frustrating to have all my work go to waste. This app used only a handle of requests per week, nothing that would be even remotely usable for someone trying to build an AI model, so I don't see why aggressive rate limits couldn't have been used to at least mitigate some of the damage from this change.

Many of the posters here have spend months working on university projects or apps for the Spotify community, only to have it ripped out from under them. I can't imagine failing a class just because financial stakeholders are concerned about maintaining a competitive advantage. Given the number of 3rd party apps that use the API, there should have been a lot more empathy for developers and end users factored into this decision.

Obviously, I hope Spotify will reconsider this decision and take this situation into account when making future decisions. Given the time it must have taken to implement these changes though, it is clear that this was a decision purposefully made with little regard for the impact on the community.

As a user, I don't think I can swear off Spotify just yet, but I will taking this opportunity to explore outside the walled garden. As a developer, it may be a better use of our time to focus on open-source, community-driven projects, and services that don't deprecate endpoints on a whim.

[sylvesta]

100,000 new songs hit Spotify daily.  Spotify needs developers to have an API so we can get ahead of the tsunami of music discovery.  Unless everyone is happy with the Top 100 or Top 1000.  It's really quite unforgivable to brick the only possibility at letting new voices be heard and new musicians shining.  Spotify, our whole project was dedicated to improving music discovery, and not even competing with Spotify but actually encouraging people to get premium subs so they could unlock these cool new discovery features.  It's something I really hope you will reconsider and change your mind about because the world deserves great music, great discovery options, and great APIs to develop on for just that.  If you would give us insight into why you are currently so opposed to this that would be helpful, maybe we can brainstorm a solution together.  As, there are many very smart developers in this very thread eager for a way to solve this mess.  Perhaps we can find an amenable solution to all parties, without the need to devastate the ecosystem of applications overnight.  Please, please, please reconsider and re-enable the APIs.  Otherwise, we will have to do things in a ghetto, jerry-rigged, bootleg way that will never be as smooth or feature rich.  And, it opens up a competitive blindspot where the first platform to create a global, current, and developer-friendly music library will win.  Frankly, I don't see how such a decision can play out in Spotify's favor, and the PR hit will be tremendous.

[thesystemera]

Couldn't agree more with this. That's the thing I don't truly understand. The use of our app required Spotify Premium and was something we were hammering home to our early beta-testers. Despite many folk asking if we could do this for YouTube Music or Apple Music, we stuck with Spotify on this one, due to their audio features / analytics. Now that this has happened, we are in the position of looking at alternative ways of getting similar data and therefor are no longer tied to Spotify Premium in anyway anymore or of any benefit. I really do feel that this anti-competitive behavour, where the competition is essentially still bringing in the bacon, just doesn't make any sense. A friend of mine, co-founder of Serato had this situation some years back and he did warn me, I feel like an **bleep** not taking is serious, as I couldn't see the reasoning behind this. Still don't understnad the business reasoning behind this. They could literally make it so that you need a Premium account to access these end-points, wouldn't that technically fix the issue, though not perfect, assures that Spotify benefit from this whole thing nonetheless. 

[Elmoesdios]

It's truly outstanding how you claim that third-party integrations "play an important role in the way users can experience the Spotify experience" but then keep restricting an API that was already incredibly limited. You did this without early notice and literally made tons of developers feel mistreated and **bleep** off as they wasted hours of development, care, and love into building apps for Spotify. Not only that, but you did it in the worst possible way. Endpoints accessing playlists now return `null` in search results instead of even filtering out. To be honest, this just feels like some exec moron was pushing to ban access to content and some intern did it in the shittiest possible way.

Ridiculous.

[Kalpik]

I would love for someone to build a web scraper that could list the tracks of Spotify owned playlists.

[Nyko_Dev]

And the Spotify team is still silent.
Please give us at least some feedback, some explanation, I don't know.

At least a "We heard your concerns and we are thinking about it" or "We heard your concerns and we don't care"

To know where we stand

[yunnancharm]

I appreciate Spotify’s commitment to security, but I hope you reconsider rolling back Web API access to its previous levels. As a university lecturer, I teach music business using Spotify data, The API has been instrumental in engaging students, many of whom sign up as free or premium Spotify users to participate in these exercises. This has been a win-win: Spotify gains new users, and students gain hands-on learning opportunities.

This new change means we may have to switch to other platforms like Last.fm, which would be unfortunate for both educators and students. While I understand concerns about unethical data use, keeping the API open is a key strength of Spotify and benefits all stakeholders. Please consider the impact on advanced users and educators.

[not-ron]

aw man this sucks 😞
spent so long working on a project that is a lot less fun now, please keep us updated if there are any workarounds 

[morrisMC]

Here is a small readme addition for the top of all of your broken public github repositories:

> ⚠️ **IMPORTANT NOTICE**

>

> Spotify has announced the deprecation of several key features in their Web API, effective **27th November**. Unfortunately, they provided limited details regarding this change.

>

> 🔗 For more (but not much) information, see their announcement: [Introducing some changes to our Web API](https://community.spotify.com/t5/Spotify-for-Developers/Changes-to-Web-API/td-p/6540414).

>

> ❤️ Love supporting artists? Consider trying Apple Music, which reportedly pays **double the royalties** to artists: [Subscribe to Apple Music](https://music.apple.com/us/subscribe).