Spotify Disables Web Player Cookie Credential Authorization Token Support

[thlucas1]

As of 2025/05/07, it appears Spotify developers have disabled the ability to utilize the Spotify Web Player Cookie Credentials (e.g. SP_DC and SP_KEY) authorization token when sending commands to their Spotify Web API.

This is disappointing, in that Spotify continues to limit functionality for its Premium content subscribers. Home Assistant users are not trying to steal company data or train AI models; we are simply trying to play our music and control our devices via home automation routines. Why can't the Spotify Web API do the same things that the Spotify Web / Mobile / Desktop applications do for Spotify Premium membership from a programmatic level?!

What Does This Mean To Me?

Various SpotifyPlus integration services and functionality will no longer work as designed / documented for Spotify PREMIUM users:

• cannot activate Google Cast devices that have went into sleep mode / idle state.
• cannot transfer playback (e.g. select source) to ANY device if Spotify Web Player Cookie Credentials are enabled.
• the following services will be immediately deprecated: GetArtistRelatedArtists, GetTrackRecommendations, GetTracksAudioFeatures, GetFeaturedPlaylists, GetCategoryPlaylists, GetGenres
• any Algorithmic and Spotify-owned editorial playlists are no longer accessible or have more limited functionality. This means that you can no longer obtain details via the GetPlaylist and GetPlaylistItems services for Spotify-owned / generated content (e.g. "Made For You", etc). A 404 - Not Found error will be returned when trying to retrieve information for these playlist types.
• for Sonos devices, any calls to Player Media Play Context, Player Media Play Tracks, or Player Media Play Track Favorites will cause content to be played on the Sonos device local queue. The local queue content that is currently playing will be different than what the Spotify Web API is currently reporting as playing; in other words, what is playing on the Sonos device will be different than what is reported as playing on the Spotify Mobile / Web / Desktop App.

Various SpotifyPlus integration services and functionality will no longer work as designed / documented for Spotify FREE users:

• cannot transfer playback (e.g. select source) to ANY device.
• can no longer control basic player functions (next track, play, pause, volume up / down, etc). You must use an official Spotify Player App to control the player.

What Do I Need To Do?

The only thing you can do until (IF?) this gets resolved is to remove the SpotifyPlus integration Spotify Web Player Credentials configuration options (e.g. SP_DC and SP_KEY values).

This will fix some of the related issues, but not all.

[ 1.0.123 ] - 2025/05/12 Update

• Restored ability to activate Google Chromecast devices from idle / sleep state. Follow the steps in the Spotify Desktop Player Authentication Configuration guide to enable this functionality.
• Removed Spotify Web Player credentials from integration configuration options. These credentials were disabled by Spotify for use with the spotify Web API on 2025/05/07.
• Removed extra state attribute sp_user_has_web_player_credentials.
• Updated underlying spotifywebapipython package requirement to version 1.0.207.

Where Do We Go From Here?

Not sure, as I am still researching what is now broken by this unexpected change.
I will keep posting to this thread as things develop.

Related Link

The following products / services are also having issues with this; I am adding links here for reference.

• Spotcast Amazon Echo - issue 403
• Spotcast Google Cast - issue 543

[fcusson]

@thlucas1 the ticket you linked is regarding an amazon echo not a cast device. There is currently no active ticket on that one.

[daspiderboris]

So is it correct to assume that v5 will resolve this by using oath?

[fcusson]

@daspiderboris sadly no I wanted to inform the ticket referenced is not related to the issue since I was aboit to close it for being a duplicate (sorry for the ambiguous message, I've been in meetings all day and trying to keep up with the issues between them)

The public Api and its available scopes doesn't allow for registering a Chromecast device.

The good news is that the issue is not at getting a token, it's at the device fetching, the error seems to indicate the endpoint used in the past no longer exist, this could be indicative that it simply changed location and a network analysis from the browser could provide more details about how to fix it. I'll be able to work on that maybe Thursday after work.

[daspiderboris]

@fcusson, noted. Thank you for your time and effort, it's greatly appreciated.

[Zelaf]

This is pure bullshittery. The past few days my very meticulously setup morning routines have been broken and it's so sad to hear about this.

I specifically switched from YouTube Music over to Spotify just before the first API lockdown and then they borked up the key thing a while back driving you nuts and now this making it even worse.

I've been thinking of switching music provider yet again. Seems like progress of some of the YouTube Music extensions have gotten better but as I have a degoogled phone, third party app support is not that good. Deezer seems to be the other alternative but haven't looked into the details of how well it works on home assistant. But I know I'm for sure ready to give up on Spotify.

Which is also very sad because I love your work on this extension and all your commited time and maintenance on it I'll always be extremely grateful for.

I hope things get better in the future and that Spotify will change it's mind about things but sadly, the API users are a minority in their wallet so they probably don't give two shits.

[Gd1230]

for the layman, is this why my kids bed time routine script isn't auto starting his bed time playlist on his google home mini?

[rvanmaanen]

for the layman, is this why my kids bed time routine script isn't auto starting his bed time playlist on his google home mini?

Yes, think so. A workaround could be to expose an entity to Google and have a Google routine trigger on changes to that entity and then start the playlist from there.. not ideal though and haven't tested this myself so no idea how reliable this would be.

Look here https://www.home-assistant.io/voice_control/voice_remote_expose_devices/ and here https://support.google.com/googlenest/answer/7029585

[thlucas1]

@Gd1230 That is correct. Any Google device using the Google Cast protocol cannot be "re-awakened" from idle / sleep state due to this issue.

[Pirol62]

Yes, deleting sp_dc and sp_key out of the configuration solves my issues. I can start playlists and select other devices. But how identifies the integration now at spotify.com i.e in case of restarting HA?

[thlucas1]

I was able to restore the ability re-activate Google Chromecast devices, but it requires some (fairly) advanced configuration (running a Python script, and modifying a JSON formatted file). Follow the steps in the Spotify Desktop Player Authentication Configuration guide to enable this functionality. Note for Sonos users - this is the same script / modification that you ran for your Sonos setup. If you have Chromecasts, you should not have to run it again.

[ 1.0.123 ] - 2025/05/12

• Restored ability to activate Google Chromecast devices from idle / sleep state. Follow the steps in the Spotify Desktop Player Authentication Configuration guide to enable this functionality.
• Removed Spotify Web Player credentials from integration configuration options. These credentials were disabled by Spotify for use with the spotify Web API on 2025/05/07.
• Removed extra state attribute sp_user_has_web_player_credentials.
• Updated underlying spotifywebapipython package requirement to version 1.0.207.

[fcusson]

@thlucas1 could you give a bit of context on what credentials you are using for it. I'll have a look if that could be feasible for spotcast to integrate an equivalent credentials scheme

[thlucas1]

@fcusson I was in the process of replying to your Issue 543 when I saw your email. Check there for more details. Hope it helps!

[thlucas1]

@Pirol62

But how identifies the integration now at spotify.com i.e in case of restarting HA?

I don’t understand the question ….

[Pirol62]

Maybe I understood things wrong. It is clear, that the intergration logs in with user and password. But what is the sp_dc and sp_key then exactly for. My suggestion was, that these credentials are necessary for communication with the spotify service. Seem to be a little confused now ;-) Spotcast uses sp_dc and sp_key as well, spotify integration uses client id and client secret......

PS: I got it. Somewhere in the community thread was the explanation. SP_DC is only used for web players like google chromecast. That was not clear for me when reading the wiki.

[JulioVillamizar]

The new process with Python is not that complicated. I did it with two accounts and it works perfectly. Thanks @thlucas1

[quizzical86]

@thlucas1 just to say thank you for the effort you did to have tried to restore functionality, really shameful that Spotify keeps maximising efforts to block this while we're clearly using it for entirely legitimate purposes.

[mdkeller25]

I have read through this issue as well as comments bu t would like some clarification. I know I'm impacted by this change. My spotify integration can no longer select a player source as it once did. I get an error "Could not select source. Not found" even though it's in the available speakers list. This is true for my Amazon devices along with my BluOS devices. Looking through the logs there isn't much to go by to identify the issue.

Reading through this I don't see where there is a fix or work around for this yet. Can someone confirm? Thanks.

[thlucas1]

@mdkeller25 Copied comment from 5 days ago …

I was able to restore the ability re-activate Google Chromecast devices, but it requires some (fairly) advanced configuration (running a Python script, and modifying a JSON formatted file). Follow the steps in the Spotify Desktop Player Authentication Configuration guide to enable this functionality. Note for Sonos users - this is the same script / modification that you ran for your Sonos setup. If you have Chromecasts, you should not have to run it again.

[ 1.0.123 ] - 2025/05/12

• Restored ability to activate Google Chromecast devices from idle / sleep state. Follow the steps in the Spotify Desktop Player Authentication Configuration guide to enable this functionality.
• Removed Spotify Web Player credentials from integration configuration options. These credentials were disabled by Spotify for use with the spotify Web API on 2025/05/07.
• Removed extra state attribute sp_user_has_web_player_credentials.
• Updated underlying spotifywebapipython package requirement to version 1.0.207.

[mdkeller25]

@thlucas1

Thanks for replying back to my question. I finally had some time to follow your instructions. Unfortunately I get the same results as I did before when trying to transfer playback to any of my echo devices or my BlueOs players.

[thlucas1]

@mdkeller25 I have not had any issues transferring playback to my Amazon Echo Dot. I am the only user account that is registered to the device though. Do you have multiple Amazon accounts that access these devices?

Questions

1. Do your Amazon and BluOS devices show up in the Spotify Connect device list on the Spotify Mobile App? Do they show up in the Spotify Web API Get Devices endpoint when using the Try It functionality?

2. What media player are you using to transfer playback to (e.g. SpotifyPlus Card, Mini Media Player, HA Player, etc)?

Other Things to Try

You can also test transfer playback using the Developer Tools \ Actions UI, like so (change your entity_id and device_id arguments):

action: spotifyplus.player_transfer_playback
data:
  entity_id: media_player.spotifyplus_todd_l
  device_id: Echo Dot 01
  play: true
  force_activate_device: true

To list currently registered Spotify Connect Zeroconf devices (change your entity_id argument):

action: spotifyplus.get_spotify_connect_devices
data:
  entity_id: media_player.spotifyplus_todd_l
  refresh: true

[mdkeller25]

@thlucas1 Thank you for the help.

1. Do your Amazon and BluOS devices show up in the Spotify Connect device list on the Spotify Mobile App? Do they show up in the Spotify Web API Get Devices endpoint when using the Try It functionality?

Yes they show up in the Web API Get Devices call

Mobile App view:

2. What media player are you using to transfer playback to (e.g. SpotifyPlus Card, Mini Media Player, HA Player, etc)? Answer: SpotifyPlus Card (Note this entire setup was previously working)

   View from the Card:

Error when selecting a player:

If I start playing from the mobile app the card recognizes it:

You can also test transfer playback using the Developer Tools \ Actions UI, like so (change your entity_id and device_id arguments):

Tried it and no error was thrown but it did not start playing:

To list currently registered Spotify Connect Zeroconf devices (change your entity_id argument): I tried this and it returned nothing.

[thlucas1]

@mdkeller25 You may need to do an F5 refresh after making the Get Spotify Connect Devices service call that returns response data. I noticed that starting with HA 2025.05.1, my results don't show until I do a refresh (some sort of caching issue).

UPDATE - I just noticed in the Kitchen Echo device, the Active User = 1262106790 - is that your Spotify ID? Or another family members' Spotify ID?

At this point I am not sure why things are not working, since the devices appear to be in the Spotify Web API device list.

The next step would be for you to run an Advanced SmartInspect Trace to Trace HA Integration Components. This traces the underlying SpotifyWebApiPython calls as well as the SpotifyPlus Integration calls, and tells me exactly what is happening from start to finish. Follow the instructions in the link to set it up, and let me know when you have some trace files ready. Do not attach trace files to this forum, as they contain sensitive information about your environment. I will setup a Google drive space for you to transfer them to when you're ready.

[kennyboy55]

Hi, thank you for all the effort you put into maintaining this component! The main reason I switched to SpotifyPlus was that it showed the playlist name even for 'Spotify Maintained Playlists'. However, with this change from Spotify, that functionality broke. I followed the steps to get the desktop player oath token and hoped that would restore this functionality as well, it did not sadly. Is it possible to restore this, or did Spotify break this completely? Thanks again!

[thlucas1]

@kennyboy55 Unfortunately, the Spotify changes broke that functionality and it cannot be restored. Since the playlist is one of their Algorithmic lists, they no longer allow its data to be retrieved.

[mdkeller25]

UPDATE - I just noticed in the Kitchen Echo device, the Active User = 1262106790 - is that your Spotify ID? Or another family members' Spotify ID?

Yes that is my ID.

I enabled SmartInspect as you asked. I attempted to select a player multiple times and the only information that is being written to the log file is:

'utf-8' codec can't decode byte 0xff in position 14: invalid start byte

[thlucas1]

@mdkeller25 'utf-8' codec can't decode byte 0xff in position 14: invalid start byte

I believe that error is due to encryption being enabled for multi-threaded processes. Try setting encrypt=false in the Connections argument, located in the smartinspect.cfg file to disable encryption.

[mdkeller25]

@mdkeller25 'utf-8' codec can't decode byte 0xff in position 14: invalid start byte

I believe that error is due to encryption being enabled for multi-threaded processes. Try setting encrypt=false in the Connections argument, located in the smartinspect.cfg file to disable encryption.

I entered the key you recommended, rebooted and got the same error.

; SmartInspect Logging Configuration General settings. Enabled = True Level = Debug DefaultLevel = Debug AppName = MyHA Encrypt = false

[thlucas1]

@mdkeller25 The encrypt=false is part of the Connections argument in the Logging output settings section; it is not a General Settings keyword.

Just replace the entire contents of the smartinspect.cfg file with the following, save it, and reboot HA:

; smartinspect.cfg
; SmartInspect Configuration File settings.
; Used by the following custom integrations:
; - SpotifyPlus
; - SoundTouchPlus

; SmartInspect Logging output settings.
; - Log to an unencrypted file, keeping 3 days worth of logs, with a new log file created each day.
Connections = file(filename="/config/smartinspect.sil", encrypt=false, key="123456", rotate=daily, maxparts=3, append=true)

; SmartInspect Logging Configuration General settings.
Enabled = True
Level = Debug
DefaultLevel = Debug
AppName = MyHA
        
; set defaults for new sessions
; session defaults only apply to newly added sessions and do not affect existing sessions.
SessionDefaults.Active = True
SessionDefaults.Level = Verbose
SessionDefaults.ColorBG = 0xFFFFFF

[mdkeller25]

@mdkeller25 The encrypt=false is part of the Connections argument in the Logging output settings section; it is not a General Settings keyword.

Just replace the entire contents of the smartinspect.cfg file with the following, save it, and reboot HA:

I appreciate the continued help. Sorry you stated that in your original post and I missed it. I already had it in the connection string but copied the contents you posted and replaced it in the smartinspect.cfg file and rebooted. I still get the same exact error. I see the time stamp being updated on the log file so I know it's being written to.

Any other thoughts?

[thlucas1]

@mdkeller25 I think it's trying to open the existing trace file that was formatted incorrectly due to the previous encryption settings.

Try deleting all of the config\smartinspect_*.sil files, and restarting HA. Also ensure that you have the latest SpotifyPlus integration installed.

If you have SoundTouchPlus installed (for Bose speaker support), you will need to ensure that you have the latest version of it installed as well. No need to install SoundTouchPlus if it's not installed; it uses the same SmartInspect trace library as SpotifyPlus, so both integrations have to have the same SmartInspect library version installed.