starred/go-librespot

Fork 0

mirror of https://github.com/devgianlu/go-librespot.git synced 2026-04-25 21:05:47 +03:00

[GH-ISSUE #282] Passthrough Spotify Web API always returns 429 "Too Many Requests" #170

New issue

Open

opened 2026-02-28 14:25:58 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 14:25:58 +03:00

Owner

Originally created by @PaulVanSchayck on GitHub (Jan 7, 2026).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/282

I had been using the Spotify Web API through the go-librespot API service. This was working great, but recently all my requests have started to return 429 Too many requests. Even when doing a fresh request afters hours of inactivity.

I'm doing this request:

$ curl -v http://localhost:3678/web-api/v1
*   Trying 127.0.0.1:3678...
* Connected to localhost (127.0.0.1) port 3678 (#0)
> GET /web-api/v1 HTTP/1.1
> Host: localhost:3678
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 429 Too Many Requests
< Vary: Origin
< Date: Wed, 07 Jan 2026 21:56:28 GMT
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

Doesn't seem to matter which Web API endpoint I try to use. Restarting go-librespot doesn't help. Anyone seen the same? Has Spotify changed things? I can use the Web API with the same account through https://developer.spotify.com/ just fine. I've also tried re-authenticating go-librespot (running in interactive mode).

Originally created by @PaulVanSchayck on GitHub (Jan 7, 2026). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/282 I had been using the Spotify Web API through the go-librespot API service. This was working great, but recently all my requests have started to return `429 Too many requests`. Even when doing a fresh request afters hours of inactivity. I'm doing this request: ``` $ curl -v http://localhost:3678/web-api/v1 * Trying 127.0.0.1:3678... * Connected to localhost (127.0.0.1) port 3678 (#0) > GET /web-api/v1 HTTP/1.1 > Host: localhost:3678 > User-Agent: curl/7.88.1 > Accept: */* > < HTTP/1.1 429 Too Many Requests < Vary: Origin < Date: Wed, 07 Jan 2026 21:56:28 GMT < Content-Length: 0 < * Connection #0 to host localhost left intact ``` Doesn't seem to matter which Web API endpoint I try to use. Restarting go-librespot doesn't help. Anyone seen the same? Has Spotify changed things? I can use the Web API with the same account through https://developer.spotify.com/ just fine. I've also tried re-authenticating go-librespot (running in interactive mode).

kerem added the

bug

spotify-side

labels

2026-02-28 14:25:58 +03:00

kerem commented

2026-02-28 14:25:59 +03:00

Author

Owner

@seijikun commented on GitHub (Jan 17, 2026):

Same thing has been seen with the python version: https://github.com/kokarare1212/librespot-python/issues/328
as well as the rust version. So it's at least not library specific (if I understood the issue correctly - but I guess it's due to the oauth token either way)

@seijikun commented on GitHub (Jan 17, 2026): Same thing has been seen with the python version: https://github.com/kokarare1212/librespot-python/issues/328 as well as the rust version. So it's at least not library specific (if I understood the issue correctly - but I guess it's due to the oauth token either way)

kerem commented

2026-02-28 14:25:59 +03:00

Author

Owner

@devgianlu commented on GitHub (Jan 23, 2026):

This doesn't look like something we can solve, perhaps they started disallowing API requests made with an OAuth token obtained with the desktop client ID.

@devgianlu commented on GitHub (Jan 23, 2026): This doesn't look like something we can solve, perhaps they started disallowing API requests made with an OAuth token obtained with the desktop client ID.

kerem commented

2026-02-28 14:25:59 +03:00

Author

Owner

@stronk-dev commented on GitHub (Feb 21, 2026):

I ran into this, but was able to solve it by modifying the web-api endpoint to use a configurable developer API token.

Can make it a PR after some more testing & reviewing it thoroughly as Claude wrote the code.

If you want to try out if this works for you before then, I can make it a draft PR or you can cherry pick from here: github.com/stronk-dev/go-librespot@0295f1a7ae

@stronk-dev commented on GitHub (Feb 21, 2026): I ran into this, but was able to solve it by modifying the `web-api` endpoint to use a configurable developer API token. Can make it a PR after some more testing & reviewing it thoroughly as Claude wrote the code. If you want to try out if this works for you before then, I can make it a draft PR or you can cherry pick from here: https://github.com/stronk-dev/go-librespot/commit/0295f1a7ae648fed2bd5f48bc372e01d1625a910

kerem commented

2026-02-28 14:25:59 +03:00

Author

Owner

@kingosticks commented on GitHub (Feb 21, 2026):

Just note that user API accounts have restricted access. You won't be able to use them with certain endpoints or Spotify owned playlists.

@kingosticks commented on GitHub (Feb 21, 2026): Just note that user API accounts have restricted access. You won't be able to use them with certain endpoints or Spotify owned playlists.

kerem commented

2026-02-28 14:25:59 +03:00

Author

Owner

@stronk-dev commented on GitHub (Feb 22, 2026):

Good point...

Then i guess a more robust solution would be to expose what one would need the web-api for, but through the 'native' Mercury/Hermes stuff, and expose API endpoints for that...

For my use case, where i only use the /web-api/v1/playlists endpoint to get playlists (+ their owner, mosaic/album art, etc), this was quite doable to expose as a set of metadata endpoints (/metadata/rootlist, /metadata/playlist/<id>, /metadata/playlist/<id>/image, /metadata/track/<id>, etc).

Edit: github.com/devgianlu/go-librespot@e0547e7994 seems stable so far for me... it adds a bunch of 'metadata' endpoints that for my use case took away the need of the web-api passthrough entirely. Including generating a mosaic for playlists without art and caching album arts locally...
But, as i really don't have time ATM to implement this 'properly', it's been made by Claude so I don't feel like it's appropriate to make a PR for this just yet.
So this is mostly for reference for people that bump into this issue and need something quick; feel free to cherry-pick this...

@stronk-dev commented on GitHub (Feb 22, 2026): Good point... Then i guess a more robust solution would be to expose what one would need the `web-api` for, but through the 'native' Mercury/Hermes stuff, and expose API endpoints for that... For my use case, where i only use the `/web-api/v1/playlists` endpoint to get playlists (+ their owner, mosaic/album art, etc), this was quite doable to expose as a set of `metadata` endpoints (`/metadata/rootlist`, `/metadata/playlist/<id>`, `/metadata/playlist/<id>/image`, `/metadata/track/<id>`, etc). Edit: https://github.com/devgianlu/go-librespot/commit/e0547e7994fb99e00c5d7ebc3cdbe43215a6bf30 seems stable so far for me... it adds a bunch of 'metadata' endpoints that for my use case took away the need of the web-api passthrough entirely. Including generating a mosaic for playlists without art and caching album arts locally... But, as i really don't have time ATM to implement this 'properly', it's been made by Claude so I don't feel like it's appropriate to make a PR for this just yet. So this is mostly for reference for people that bump into this issue and need something quick; feel free to cherry-pick this...