[GH-ISSUE #11] List Liked Songs feature is generating 404 errors

kerem commented

2026-02-27 20:07:40 +03:00

Owner

Originally created by @tomballgithub on GitHub (May 25, 2025).
Original GitHub issue: https://github.com/misiektoja/spotify_profile_monitor/issues/11

I spent hours today trying to get the -x feature to work, which lists liked/saved songs by the user attributed to the sp_dc cookie. I subsequently saw the same behavior from a different tool I used to maintain, which makes me think there is an issue (something changed with Spotify) with the 'scope' attributed to the token fetched via this sp_dc cookie mechanism.

Debugging verified that I can access https://api.spotify.com/v1/me/ but not https://api.spotify.com/v1/me/tracks with the token generated via this utility. I was able to generate a token via the "Authorization Code Flow" method using some test code, and that worked in this utility when I hard-coded it (until it expired).

Everything still works in the utility, even the -l feature, but not -x, which is unique in that it accesses the current user's data. To access this data via other means of generating tokens requires having specific 'scopes' to be able to access this data.

Here is the output when I use -x. This feature worked a few weeks ago, although I had a different implementation in this utility before -x was implemented. Nothing works now.

Spotify Profile Monitoring Tool v2.2

* Listing liked tracks by the user owning the token ...

Token belongs to:       PJ
                        [ https://open.spotify.com/user/redacted-us?si=1 ]

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────
* Error: Playlist does not exist or is set to private: 404 Client Error: Not Found for url: https://api.spotify.com/v1/me/tracks?fields=next,total,items(added_at,track(name,uri,duration_ms),added_by),items(track(artists(name,uri)))

Originally created by @tomballgithub on GitHub (May 25, 2025). Original GitHub issue: https://github.com/misiektoja/spotify_profile_monitor/issues/11 I spent hours today trying to get the -x feature to work, which lists liked/saved songs by the user attributed to the sp_dc cookie. I subsequently saw the same behavior from a different tool I used to maintain, which makes me think there is an issue (something changed with Spotify) with the 'scope' attributed to the token fetched via this sp_dc cookie mechanism. Debugging verified that I can access https://api.spotify.com/v1/me/ but not https://api.spotify.com/v1/me/tracks with the token generated via this utility. I was able to generate a token via the "Authorization Code Flow" method using some test code, and that worked in this utility when I hard-coded it (until it expired). Everything still works in the utility, even the -l feature, but not -x, which is unique in that it accesses the current user's data. To access this data via other means of generating tokens requires having specific 'scopes' to be able to access this data. Here is the output when I use -x. This feature worked a few weeks ago, although I had a different implementation in this utility before -x was implemented. Nothing works now. ``` Spotify Profile Monitoring Tool v2.2 * Listing liked tracks by the user owning the token ... Token belongs to: PJ [ https://open.spotify.com/user/redacted-us?si=1 ] ───────────────────────────────────────────────────────────────────────────────────────────────────────────────── * Error: Playlist does not exist or is set to private: 404 Client Error: Not Found for url: https://api.spotify.com/v1/me/tracks?fields=next,total,items(added_at,track(name,uri,duration_ms),added_by),items(track(artists(name,uri))) ```

kerem closed this issue

2026-02-27 20:07:40 +03:00

kerem commented

2026-02-27 20:07:40 +03:00

Author

Owner

@misiektoja commented on GitHub (May 25, 2025):

Hey, yes, I confirm Spotify changed the scope of access tokens generated via the sp_dc mechanism. I'm experiencing the same behavior. It worked a few days ago, so the change is recent.

One way would be to incorporate the Client Credentials Flow as I already did for lastfm_monitor to cover some functionality. However, using two ways to get Spotify data is not something I like.

In the meantime I am working on a new way of fetching access tokens that are as powerful as the old ones (so called "god mode" ;-)). I already have a working PoC, but this is still a kind of "hack" approach using an intercepted client token from the real Spotify client. But ... it looks very promising, as I believe I will be able to avoid refreshing the token every two weeks as required by recent Spotify changes. I'll keep you posted. I just need to find more time to fully validate and finalise my ideas as it requires heavy usage of Protobufs and most stuff is not really documented, so I'm reverse engineering it.

@misiektoja commented on GitHub (May 25, 2025): Hey, yes, I confirm Spotify changed the scope of access tokens generated via the sp_dc mechanism. I'm experiencing the same behavior. It worked a few days ago, so the change is recent. One way would be to incorporate the Client Credentials Flow as I already did for lastfm_monitor to cover some functionality. However, using two ways to get Spotify data is not something I like. In the meantime I am working on a new way of fetching access tokens that are as powerful as the old ones (so called "god mode" ;-)). I already have a working PoC, but this is still a kind of "hack" approach using an intercepted client token from the real Spotify client. But ... it looks very promising, as I believe I will be able to avoid refreshing the token every two weeks as required by recent Spotify changes. I'll keep you posted. I just need to find more time to fully validate and finalise my ideas as it requires heavy usage of Protobufs and most stuff is not really documented, so I'm reverse engineering it.

kerem commented

2026-02-27 20:07:40 +03:00

Author

Owner

@tomballgithub commented on GitHub (May 26, 2025):

Well, I verified this yesterday, but quoting online info "Since the Client Credentials flow does not include authorization, only endpoints that do not access user information can be accessed." as well as "In order to call the /v1/me/tracks endpoint you'll need an access token obtained through one of the other flows - like the authorization code flow. You're right that this means authenticating on the web at least once. Your app can use the refresh token to obtain a new access token when the access token you have expires."

So, Client Credentials isn't a viable plan B; it would need to be a different mechanism if this 'god mode' doesn't work

@tomballgithub commented on GitHub (May 26, 2025): Well, I verified this yesterday, but quoting online info "Since the Client Credentials flow does not include authorization, only endpoints that do not access user information can be accessed." as well as "In order to call the /v1/me/tracks endpoint you'll need an access token obtained through one of the other flows - like the authorization code flow. You're right that this means authenticating on the web at least once. Your app can use the refresh token to obtain a new access token when the access token you have expires." So, Client Credentials isn't a viable plan B; it would need to be a different mechanism if this 'god mode' doesn't work

kerem commented

2026-02-27 20:07:41 +03:00

Author

Owner

@tomballgithub commented on GitHub (May 26, 2025):

Interesting; searching for spotify tokens god mode yielded nothing. I will await the results of your experiments. Hope they work!

@tomballgithub commented on GitHub (May 26, 2025): Interesting; searching for spotify tokens god mode yielded nothing. I will await the results of your experiments. Hope they work!

kerem commented

2026-02-27 20:07:41 +03:00

Author

Owner

@misiektoja commented on GitHub (May 26, 2025):

Valid point about Client Credentials flow not being usable for this purpose!

But Spotify has some other auth flows as well and looking at the options I think Authorization Code Flow with PKCE should work for this and it is supported by Spotify - check out the SpotifyPKCE auth manager.

As for the so-called "god mode", it is not something anybody has done so far. I was just fooling around with Spotify's Protobufs and the crazy idea came to somehow fully replicate the official Spotify client behaviour.

@misiektoja commented on GitHub (May 26, 2025): Valid point about Client Credentials flow not being usable for this purpose! But Spotify has some other auth flows as well and looking at the options I think Authorization Code Flow with PKCE should work for this and it is supported by Spotify - check out the SpotifyPKCE auth manager. As for the so-called "god mode", it is not something anybody has done so far. I was just fooling around with Spotify's Protobufs and the crazy idea came to somehow fully replicate the official Spotify client behaviour.

kerem commented

2026-02-27 20:07:41 +03:00

Author

Owner

@tomballgithub commented on GitHub (May 26, 2025):

As for the so-called "god mode", it is not something anybody has done so far. I was just fooling around with Spotify's Protobufs and the crazy idea came to somehow fully replicate the official Spotify client behaviour.

Well, obviously the web client does have full scope, so it will be interesting if you are able to reverse engineer it

@tomballgithub commented on GitHub (May 26, 2025): `As for the so-called "god mode", it is not something anybody has done so far. I was just fooling around with Spotify's Protobufs and the crazy idea came to somehow fully replicate the official Spotify client behaviour.` Well, obviously the web client does have full scope, so it will be interesting if you are able to reverse engineer it

kerem commented

2026-02-27 20:07:41 +03:00

Author

Owner

@tomballgithub commented on GitHub (May 26, 2025):

Authorization Code Flow is what I used yesterday for testing. I don't really need to run -x frequently, but having it automated would be great because I am using it in a scripted manner.

@tomballgithub commented on GitHub (May 26, 2025): Authorization Code Flow is what I used yesterday for testing. I don't really need to run -x frequently, but having it automated would be great because I am using it in a scripted manner.

kerem commented

2026-02-27 20:07:41 +03:00

Author

Owner

@misiektoja commented on GitHub (Jun 9, 2025):

Ok, I've got some good news! Boredom struck hard today, so I went on a side quest to fully reverse-engineer Spotify's magical Protobuf structures and I managed to get it working with a fully automatic refresh of client and access tokens. It actually works surprisingly well with very wide token scope, so getting the list of liked tracks works again. Funny thing is, the refresh token seems to be valid forever (or so it seems as documentation does not say it ever expires), which means the tool should work indefinitely. Check out the Spotify Desktop Client for more info.

@misiektoja commented on GitHub (Jun 9, 2025): Ok, I've got some good news! Boredom struck hard today, so I went on a side quest to fully reverse-engineer Spotify's magical Protobuf structures and I managed to get it working with a fully automatic refresh of client and access tokens. It actually works surprisingly well with very wide token scope, so getting the list of liked tracks works again. Funny thing is, the refresh token seems to be valid forever (or so it seems as documentation does not say it ever expires), which means the tool should work indefinitely. Check out the [Spotify Desktop Client](https://github.com/misiektoja/spotify_profile_monitor/blob/main/README.md#spotify-desktop-client) for more info.

kerem referenced this issue

2026-02-27 20:07:46 +03:00

[PR #8] [CLOSED] Original JMK changes #24

Rows
Columns

[GH-ISSUE #11] List Liked Songs feature is generating 404 errors #8