mirror of
https://github.com/jpochyla/psst.git
synced 2026-04-27 07:25:52 +03:00
[GH-ISSUE #719] HTTP Status: 429 #404
Labels
No labels
api
bug
build
documentation
duplicate
enhancement
good first issue
help wanted
idea
invalid
linux
lowprio
macos
pull-request
upstream
windows
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/psst#404
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 @babochyk on GitHub (Dec 23, 2025).
Original GitHub issue: https://github.com/jpochyla/psst/issues/719
Describe the bug
Upon launching psst, no tracks load, the sidebar says http status: 429, but the home page does.
To Reproduce
Launch psst
Click on any playlist on the home page or select any other page.
Expected behavior
The tracks and the sidebar should load tracks.
Screenshots
Environment
Additional context
I switched to psst because ncspot started lagging.
@jtaub commented on GitHub (Dec 23, 2025):
Same problem here on Ubuntu 25.10. Worked until latest pull. Official Spotify website and app are working without 429, so I don't think my account is being rate limited.
@AuryVaz commented on GitHub (Dec 23, 2025):
Same here, Arch Linux too.
@notrudyyy commented on GitHub (Dec 24, 2025):
Happening on Fedora 43 KDE Plasma spin too.
@gslin commented on GitHub (Dec 24, 2025):
Maybe related to the latest Anna's Archive news as Spotify said they've implemented some safe-guard mechanisms.
@notrudyyy commented on GitHub (Dec 24, 2025):
Wow can't believe they did that. If the cost is me using the web player for a while so be it!
@Pogodaanton commented on GitHub (Dec 24, 2025):
Related discussions:
https://github.com/hrkfdn/ncspot/issues/1757
https://github.com/aome510/spotify-player/issues/890
@Cleboost commented on GitHub (Dec 25, 2025):
Same
@monskov commented on GitHub (Dec 27, 2025):
same issue, on arch
@timstapl commented on GitHub (Dec 28, 2025):
It looks like 429 from spotify is your api key being rate limited. Maybe adding a setting where users can provide their own api key, similar to the last.fm config, would be a decent workaround?
@wizardwithcodehazard commented on GitHub (Dec 29, 2025):
I feel like its because of anna's archive doing the spotify meta data download sh..t. 429 means too many requests idk should get resolved or what's happening..
@Potherca commented on GitHub (Dec 29, 2025):
Oddly, this does not happen when using another client, like Riff. If the issue was with Spotify, I would expect to see 429s there too. 🤔
@Pogodaanton commented on GitHub (Jan 4, 2026):
Interesting...
Riff uses a custom
client_idthat was created when it was still maintained asspot. I did not know that you were able to register applications on Spotify that are granted the necessary scopes to use librespot-playback.The auth token psst obtains seems to have been blocked for anything touching the
api.spotify.comendpoint. For psst, this includes most requests in the GUI and metadata retrieval for playback. That's also why the home section on psst still works partially though: Those requests go to a different endpoint.Resolving playback for psst with the current token is trivial. Accessing track lists with the current token, however, will require a change to a different endpoint. The pathfinder API, which is already used in the home section, could be a potential choice. It still works with the current token. As that API has a completely different output and barely any documentation, this might become a time-consuming do-over.
Alternatively, we could get a hold of a registered
client_idthat has streaming scopes among others and base (all) API requests on that. This would still require a change in how tokens are retrieved and refreshed (akin to #694). I don't know when and if obtaining such an ID is possible any time soon, as Spotify has (quietly?) paused application registrations for now.Otherwise, 'bring your own api key' is also a viable option. However, that will be hard to test/use for people who don't have one (e.g. me), given that Spotify has paused paused application registrations for now.
@kingosticks commented on GitHub (Jan 4, 2026):
The (historical) problems with personal client IDs is they have more usage restrictions. Specifically, lower rate-limits and no access to some endpoints. But that's all moot if the traditional shared client ID has now been crippled in Spotify's latest hissy fit/panic.
@jacksongoode commented on GitHub (Jan 5, 2026):
Yeah - I've been following and patiently waiting to see how other projects are approaching this. It might just mean adding some rate limiting to our requests to prevent this from happening.
@Pogodaanton Thanks for the investigation! I think given that Spotify might be making some changes re: api access, I think there will just be more and more work ahead until they make an announcement.
@kingosticks commented on GitHub (Jan 8, 2026):
It's also currently not possible to obtain a personal client ID, Spotify have quietly disabled new applications.
@rublev commented on GitHub (Feb 13, 2026):
429 on macos too D:
@rmoeritz-alayacare commented on GitHub (Feb 19, 2026):
Yep, on starting Psst I immediately get a wall of 429s making it unusable 😢. What a shame (Ubuntu 24.04 x64).
@evs-xsarus commented on GitHub (Feb 20, 2026):
This is possible again. Could psst be enhanced with the new URL Oauth https://developer.spotify.com/documentation/web-api/concepts/authorization
@ralph commented on GitHub (Feb 20, 2026):
Now that client id registrations are open again, Psst could be converted to bring-your-own-client-id, meaning each user must register her/his own client id on the Spotify developer dashboard. This will get rid of the 429s, but comes at the cost of more restrictions, as described here:
There is no easy solution for this, unfortunately. Spotify decided it doesn't need indie developers, so maybe indie developers will decide they don't need Spotify next
¯\_(ツ)_/¯.@evs-xsarus commented on GitHub (Feb 20, 2026):
Maybe those limits are enough for us users. I've got the authentication working in these clients:
You might be able to borrow stuff from them.
@ralph commented on GitHub (Feb 20, 2026):
Also https://github.com/ralph/Spotifly if you prefer a GUI client 😇
@Potherca commented on GitHub (Feb 20, 2026):
... and are on mac. 😞
@Pogodaanton commented on GitHub (Feb 21, 2026):
From what I can tell based on the way the announcement post was phrased, they'd prefer this project (and broadly most open source projects) to use a bring-your-own-key model.
Using developer keys should bring back most of psst's basic features like browsing and playback if clients like Spotifly work with the new keys. Stuff like credits and the home page will likely not be accessible anymore.
The only real hurdle right now is that the current authentication system in psst relies on tokens from login5 which will most likely not be accessible with developer keys. So we need to scrap login5 (🥲) and figure out a full OAuth refresh token based authentication system (akin to #694 ), so that we remove all reliance on the currently used client id. Then bring-your-own-key can be implemented.
Sadly I don't have the time to do this right now, so hopefully somebody can pick up the work based on the little explanation above
@grenaad commented on GitHub (Feb 21, 2026):
See pr here, this is based of work from @evs-xsarus, thank you for sharing that.
I did get it working, just need to add a client id, see the description.