mirror of
https://github.com/misiektoja/spotify_monitor.git
synced 2026-04-25 22:55:52 +03:00
[GH-ISSUE #27] API Looks broken again #18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tomballgithub on GitHub (Dec 22, 2025).
Original GitHub issue: https://github.com/misiektoja/spotify_monitor/issues/27
The API stopped working for me today with the latest codes from spotify_monitor_secret_grabber.py
{"59":[123,105,79,70,110,59,52,125,60,49,80,70,89,75,80,86,63,53,123,37,117,49,52,93,77,62,47,86,48,104,68,72],"60":[79,109,69,123,90,65,46,74,94,34,58,48,70,71,92,85,122,63,91,64,87,87],"61":[44,55,47,42,70,40,34,114,76,74,50,111,120,97,75,76,94,102,43,69,49,120,118,80,64,78]}@misiektoja commented on GitHub (Dec 23, 2025):
Hey, I already commented in other thread here.
@tomballgithub commented on GitHub (Dec 23, 2025):
@misiektoja
You mentioned 429's at that link, but FYI I am seeing this (400) from 'spotify_profile_monitor' and 'spotify_monitor'.
I've been using 'cookie' method.
* Error: sp_dc may be invalid/expired or Spotify has broken sth again! Failed to obtain a valid Spotify access token after 3 attempts: refresh_access_token_from_sp_dc(): Unsuccessful token request: 400 Client Error: Bad Request for url: https://open.spotify.com/api/token?reason=init&productType=web-player&totp=011654&totpServer=011654&totpVer=0&sTime=1766458607&cTime=1766458606538&buildDate=2025-12-23&buildVer=web-player_2025-12-23_1766458607000_ddb1c8d5@0xXiHan commented on GitHub (Dec 23, 2025):
I also encountered the same problem early this morning, to the point that all related services were suspended.
@0xXiHan commented on GitHub (Dec 23, 2025):
Is Spotify conducting large-scale account risk control today?
@tomballgithub commented on GitHub (Dec 23, 2025):
The thing is, the web page using the same sp_dc cookie without issue. There could be something new going on with the requests that are unrelated to the token.
@tomballgithub commented on GitHub (Dec 24, 2025):
FWIW, spotify_profile_monitor works with both oauth_app and oauth_user with the known limitations.
Client and Cookie mode do not work, which are the only supported modes for spotify_monitor
@tomballgithub commented on GitHub (Dec 24, 2025):
@misiektoja I emailed you some sample code that is working
@misiektoja commented on GitHub (Dec 25, 2025):
Hey, I checked quickly how SpotifyFLAC fixed it. They essentially switched from the open.spotify.com endpoint (TOTP-based), to the official Spotify Web API using the Client Credentials OAuth flow - it is the oauth_app already implemented in spotify_profile_monitor. However, this does not allow fetching friends' listening activity, i.e. we need user-authenticated tokens (via sp_dc cookie or refresh token), so it does not really help in spotify_monitor.
It looks like a more complex task since I need to examine the JS client side and Spotify app to determine their current behaviour. Hopefully, we can restore at least one option (cookie or client). However, even if we manage to get it working again, I am concerned that they might have blocked many endpoints, as @Thereallo1026 mentioned in the email I received.
@0xXiHan commented on GitHub (Dec 25, 2025):
Are there any new solutions for obtaining auth token now? @misiektoja
@misiektoja commented on GitHub (Dec 25, 2025):
I briefly examined the network traffic from open.spotify.com and it appears that a client-token is now required in the request headers for many endpoints. We need to figure out how it is assigned. I will try to look into it more deeply in a few days. We have Christmas here and I am going from place to place visiting family ;-)
@0xXiHan commented on GitHub (Dec 25, 2025):
Thank you so much, bro! Your project has been a huge help to me. Merry Christmas to you!
@Thereallo1026 commented on GitHub (Dec 25, 2025):
Client token comes from
https://clienttoken.spotify.com/v1/clienttoken:And two endpoints for server time:
https://gae2-spclient.spotify.com/melody/v1/time(Requires auth headers)https://open.spotify.com/api/server-timeData comes from
https://api-partner.spotify.com/pathfinder/v2/query(GraphQL, requires bothclient-tokenandauthorizationheader, andsha256Hashin request payload)Merry Christmas, cheers 🙌
@tomballgithub commented on GitHub (Dec 25, 2025):
I have been looking at the requests and responses of the web interface and python code using 'Proxyman'. Here are a sample good requests and responses associated with the URLs @Thereallo1026 shared above. All of these were using the web interface.
Additionally, comparing the TOTP between the spotify web interface and the python code, the generated TOTP's are definitely different. Not a surprise, but I wanted to mention & confirm it.
https://clienttoken.spotify.com/v1/clienttoken
With the web interface, I am seeing requests to https://open.spotify.com/api/token?reason=init to get the token. This is where I am seeing a TOTP that doesn't match the python code when generated at the same time. For example:
For time, I am seeing https://guc3-spclient.spotify.com/melody/v1/time with the Spotify web browser version:
For time, if I manually do a request to https://open.spotify.com/api/server-time:
https://api-partner.spotify.com/pathfinder/v2/query:
@0xXiHan commented on GitHub (Dec 25, 2025):
Hey bro, I think I've solved my problem. I made the check_token_validity function return True directly, and I can determine the availability of sp_dc through some downstream interfaces.
@tomballgithub commented on GitHub (Dec 25, 2025):
I verified that all three URLs return the same thing for 'Date'. The first requires auth headers; in its absence, it still returns 'Date' but not 'timestamp'. You can see 'timestamp' or 'serverTime' returned in my examples above, and I verified that both match the associated 'Date'.
All this to say, if TOTP is incorrect, it shouldn't be because the date URLs have changed.
@tomballgithub commented on GitHub (Dec 25, 2025):
At Thu, 25 Dec 2025 04:17:48 GMT, I see the time fetched and then a subsequent GET from https://open.spotify.com/api/token?reason=init&productType=web-player&totp=830346&totpServer=830346&totpVer=61.
If I force the time to Thu, 25 Dec 2025 04:17:48 GMT in fetch_server_time(), it generates 830346 for otp_value, which is the expected value.
So TOTP calculations still looks OK with '61'
@tomballgithub commented on GitHub (Dec 25, 2025):
Is there a bug in the code here? TOTP_VER is sent as a parameter in the URL, but the default is '0' for autodetect, which works correctly in the code for TOTP generation, but TOTP_VER never changes from '0'.
I am seeing the script with totpVer = 0 in the URL rather than 61
https://open.spotify.com/api/token?reason=init&productType=web-player&totp=108902&totpServer=108902&totpVer=0
@tomballgithub commented on GitHub (Dec 26, 2025):
I have code working that gets the 'Authorization' token and the 'client-token'
I can access these endpoints (only two I've tried):
https://guc3-spclient.spotify.com/presence-view/v1/buddylist
https://guc3-spclient.spotify.com/melody/v1/time
But https://api.spotify.com/v1/me gives me a 429 (previously I said it was a 404, but I had a url error)
I don't see the web client or the Windows client using this endpoint, so I have nothing to compare the requests to.
@misiektoja commented on GitHub (Dec 26, 2025):
Wow, that is very good news! We don't really need /v1/me for anything crucial. It was used in the
check_token_validity()function (we can use the /v1/buddylist endpoint instead) and inspotify_get_current_user()to get info about the token owner (it was for informational purposes only and not really needed for any core functionality, so we can remove it).Will you make a PR for that ?
@tomballgithub commented on GitHub (Dec 26, 2025):
@misiektoja It's nowhere close to a PR, I just got it up to being able to pass the check_token_validity. I don't understand all of the different refreshes and such that you have going on. At a minimum, I'll send you my code tonight over email.
@0xXiHan commented on GitHub (Dec 26, 2025):
The previous status code 400 occurred because it hadn't reached /v1/me yet and was still retrying to obtain the token. The check_token_validity function was being ignored. Currently, it appears that TOTP acquisition is working fine, but the official service seems to have implemented risk control measures on the /v1/me endpoint.
@tomballgithub commented on GitHub (Dec 26, 2025):
Well, I've cleaned it up a lot, but noticed something else:
spotify_get_friends_json, works: https://guc-spclient.spotify.com/presence-view/v1/buddylist
spotify_get_track_info, gives 429: https://api.spotify.com/v1/tracks/
I wonder if they are blocking https://api.spotify.com/v1/ or moved it? Or it could just be that my headers/auth need to be different for get_track_info requests.
@misiektoja commented on GitHub (Dec 26, 2025):
Hey guys, thanks to your findings I got the code fully working in both cookie and client modes!
You made me realize we need a hybrid approach. It turned out some calls still work without changes (like /v1/buddylist), but for others (like /v1/tracks or /v1/playlists) the official client credentials flow is required (oauth_app).
So I backported some code from spotify_profile_monitor and confirmed it works. Now it will require setting up two authentication modes: cookie/client and oauth_app. We need two different authentication methods because neither provides access to all API endpoints.
Let me clean up the code and I will push it to dev in a couple of minutes.
@tomballgithub commented on GitHub (Dec 26, 2025):
Yep, I see the same thing with /v1/playlists.
I spent way too much time on this today, but I do feel like getting it to work was a nice accomplishment for myself
@tomballgithub commented on GitHub (Dec 26, 2025):
Happy you got it working. Merry Xmas!
@misiektoja commented on GitHub (Dec 26, 2025):
Great work! It made fixing it an easy-peasy task! Merry Christmas to you as well!
@tomballgithub commented on GitHub (Dec 26, 2025):
Not sure if this was always the case, but this was mentioned above:
I did notice device_id being passed in the requests, and that it seems to match the web browser cookie SP_T. I'm not sure if there is some way to get this besides manually entering it like SP_DC
It does work without it, but this could be a telltale sign of a script if it's missing.
@tomballgithub commented on GitHub (Dec 26, 2025):
Did you see my comment above about ->
I am seeing the script with totpVer = 0 in the URL rather than 61
https://open.spotify.com/api/token?reason=init&productType=web-player&totp=108902&totpServer=108902&totpVer=0
@misiektoja commented on GitHub (Dec 26, 2025):
Pushed, please test and let me know if you notice any issues! I'll look into other stuff you reported hopefully tomorrow!