mirror of
https://github.com/sigma67/ytmusicapi.git
synced 2026-04-24 23:06:13 +03:00
[GH-ISSUE #813] oauth authentication: Request contains an invalid argument #506
Labels
No labels
a/b
bug
documentation
enhancement
good first issue
help wanted
invalid
pull-request
question
wontfix
yt-error
yt-update
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ytmusicapi#506
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 @sigma67 on GitHub (Sep 2, 2025).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/813
Recommended workaround: use browser based auth instead of oauth.
Discussed in https://github.com/sigma67/ytmusicapi/discussions/812
Originally posted by rawinkler September 1, 2025
Bug description
Since last Friday, August 29th 2025, suddenly my code stopped working. I use ytmusicapi version 1.11.0.
I get the error:
File "/usr/local/lib/python3.13/site-packages/ytmusicapi/mixins/search.py", line 182, in search
response = self._send_request(endpoint, body)
File "/usr/local/lib/python3.13/site-packages/ytmusicapi/ytmusic.py", line 241, in _send_request
raise YTMusicServerError(message + error)
ytmusicapi.exceptions.YTMusicServerError: Server returned HTTP 400: Bad Request.
Request contains an invalid argument.
To Reproduce
Minimal example:
Is it possible that YouTube changed something that causes ytmusicapi to break?
Thanks for any help!
@sigma67 commented on GitHub (Sep 2, 2025):
PR welcome
@Goldenfreddy0703 commented on GitHub (Sep 4, 2025):
Hey @sigma67 , Ok so im not entirely sure if this pr will help but I've forked your project and looked into it and i was able to test everything there is.
If you want, please feel free to take a look at this pr, Hopefully this helps but if not, please feel free to delete it.
Thanks
https://github.com/sigma67/ytmusicapi/pull/815
@KoljaWindeler commented on GitHub (Sep 6, 2025):
Thanks for trying @Goldenfreddy0703
The issue is certainly affecting lots of users. It also breaks the entire setup for me in Germany.
@Goldenfreddy0703 commented on GitHub (Sep 6, 2025):
Oh hey anytime @KoljaWindeler , hey so I actually got some good news, today i decided to try again and i was actually doing some coding for a whole day and what I've been doing is I've been working on the ytmusic api and getting everything to work using the ios client. I have about a third of it completed but I need to get Playlist, podcast, and uploads done and then I probably need to test every function. So far, all the other stuff is working and getting the correct params and thanks to this documentation, it's been a huge help.
https://ytmusicapi.readthedocs.io/en/stable/index.html
Hopefully by tomorrow or the next few days, I can make a pr that will pass almost every test there is.
@king-millez commented on GitHub (Sep 9, 2025):
FWIW I just used Goldenfreddy's branch to replicate some playlists on YTM and it's working nicely. Thanks!
@sigma67 commented on GitHub (Sep 9, 2025):
Not sure if related, but the Authorization header has changed as well apparently: https://github.com/sigma67/ytmusicapi/issues/813
@Aetrocles commented on GitHub (Sep 26, 2025):
Any update on this? I use the API to extract my playlist metadata... Curious if it would be duplicated effort for me to try to learn the API and find a solution... A bit overwhelmed I'm a C# .net front end developer with data model and data manipulation experience.
@kikaDev404 commented on GitHub (Sep 27, 2025):
I am also facing the same issue.
ytmusicapi.exceptions.YTMusicServerError: Server returned HTTP 400: Bad Request.I am trying to fetch the user library
@sigma67 commented on GitHub (Sep 28, 2025):
Hi all, the current solution attempt by Goldenfreddy does not work reproducibly for my account.
I still get the same error noted in the issue title. Therefore we cannot merge this right now.
Other attempts at solving this problem are in no way duplicate effort as I do not consider this problem solved right now.
Furthermore we do not know if there is currently a region-specific rollout or if the problem is the same for all regions.
@atjacobs commented on GitHub (Sep 29, 2025):
I am also experiencing this issue.
@robdupre commented on GitHub (Oct 1, 2025):
Im UK based and have the same issue unauthenticated works:
Fails:
@jorbig commented on GitHub (Oct 1, 2025):
Same problem here in The Netherlands. What is the best workaround?
@sigma67 commented on GitHub (Oct 2, 2025):
There is no solution unfortunately: https://github.com/sigma67/ytmusicapi/pull/817#issuecomment-3358576031
You must use the browser based auth variant.
You can try sending a note to Google support that they should provide some way for us to use their oauth API with YouTube Music.
But so far they've only made life harder for us over the past months, so I'm not even hoping for anything at this point.
@Goldenfreddy0703 commented on GitHub (Oct 2, 2025):
One solution I'm thinking of doing for my app is having the user connecting to a local HTTP server via localhost and having an oath of some kind to generate the cookie and all so maybe that's something I can work on tomorrow.
EDIT: Apparently, its not that simple thanks to browser security and google. ughhhhhhh.....
@DanielWeigl commented on GitHub (Oct 2, 2025):
I have tested it a bit and noticed following - if I change the clientName/version to
the oauth login works and we get a result, but its always the same and has no search results:
Changing it to
also works and even returns results, but in a different format than the current lib is expecting:
returns an empty array, but the underlying response from youtube has results:
Im not sure what needs to be adapted to correctly parse this format
@sigma67 commented on GitHub (Oct 2, 2025):
@DanielWeigl thanks for checking and confirming that the API is different. It was already noted here by @sgvictorino : https://github.com/sigma67/ytmusicapi/pull/817#issuecomment-3349552129
It seems the API is more limited than what we need so I'm not sure it's worth implementing the parsers for a limited API just for the sake of having oauth at all.
@Goldenfreddy0703 commented on GitHub (Oct 2, 2025):
Yeah TVHTML5 is basically the music section from the main youtube so wouldn't be so good. When IOS_MUSIC was working, i was actually working on the parser for it but than Google decided to be dumb so yeah.
@Aetrocles commented on GitHub (Oct 8, 2025):
I know it doesn't help with this particular API or bug but for me it was really important to get my YouTube music metadata so I can keep track of my songs and my playlists...
If you go to Google takeout you can download your YouTube data and it'll have a list of all your playlists and another file of all your library songs/videos. You can cross reference with the video ID from the two files and parse the content into a clean data structure...
You can't really automate the extraction of Google take out and I wouldn't recommend abusing it because if they remove album or artist info it would suck major... But it helps in a pinch.
@carvaofficial commented on GitHub (Oct 9, 2025):
Hi! I'm having the same problem when requesting my YouTube Music account history:
ytmusic = YTMusic(auth='oauth.json', oauth_credentials=OAuthCredentials(client_id=os.getenv("YTMUSIC_CLIENT_ID"), client_secret=os.getenv("YTMUSIC_CLIENT_SECRET"))) history = ytmusic.get_history()The log output:
ytmusic-dev | [2025-10-09 14:39:16,572] (INFO): Script start
ytmusic-dev | [2025-10-09 14:39:17,112] (ERROR): Error getting song from YouTube Music: Server returned HTTP 400: Bad Request.
ytmusic-dev | Request contains an invalid argument.
ytmusic-dev | [2025-10-09 14:39:17,112] (INFO): No song data to send.
ytmusic-dev | [2025-10-09 14:39:17,112] (INFO): Script end
@davidpelayo commented on GitHub (Nov 25, 2025):
After I would spend a few hours trying to fix this I came up with reading this Github issue. What would you say would be the alternative to try to workaround it? Or it does not have to do with the auth flow you use but rather the API being changed on Youtube's side?
@thosch6 commented on GitHub (Nov 27, 2025):
I am having the same problem, I cannot use my app to generate playlists through the ytmusicapi anymore. I'm getting:
"Failed to create playlist: Server returned HTTP 400: Bad Request. Request contains an invalid argument."
My app was working fine until recently, and the authentication itself succeeds - but playlist creation fails.
@sigma67 commented on GitHub (Dec 4, 2025):
Hi @thosch6 , have you tried the workaround to use browser-based authentication? It should work just fine.
On the oauth front we are unfortunately blocked due to YouTube Music server not accepting our requests.
@thosch6 commented on GitHub (Dec 4, 2025):
The workaround to use browser-based authentication does not work either. I tried this approach twice, the first time with the AI help of the new Gemini 3.0, a few days later with Claude Sonnet 4.5. Even though authentication poses no problem, generating playlists fails always.
"Failed to create playlist: Server returned HTTP 400: Bad Request. Request contains an invalid argument."
@sigma67 commented on GitHub (Dec 4, 2025):
That is unlikely, you might be using the wrong file by accident. That error message only occurs when using oauth (or your browser credentials are corrupt).
Did you follow the browser instructions in the documentation? Could you elaborate?
@thosch6 commented on GitHub (Dec 10, 2025):
So I tried the 3rd time creating a playlist with the latest YouTubeMusicApi version 1.11.3. It fails with error 401. Here's the detailed report assembled with Anthropic Opus 4.5:
Report: Playlist Creation Failing with Browser Authentication
Summary
Playlist creation via
ytmusicapiwith browser authentication returns HTTP 401 (Unauthorized), even though search and other read operations work fine with the same credentials.Environment
Observed Behavior
Root Cause Analysis
After extensive debugging, I found that direct HTTP requests to YouTube Music's API work perfectly when using headers copied directly from Chrome DevTools. This indicates the issue is in how
ytmusicapihandles or regenerates the authorization header.Key Finding 1: Authorization Header Format Changed
YouTube Music now uses a 3-part authorization header with
_usuffix:Instead of the previous single-part format:
Key Finding 2: Hash Generation Algorithm Differs
I tested the documented hash formula:
Result: The generated hash does NOT match what Chrome produces.
I tested multiple variations (different separators, different orders, SHA-256, etc.) - none matched Chrome's hash. This suggests YouTube may have changed the hash algorithm or is using additional inputs.
Key Finding 3: Cookies Rotate Frequently
These cookies change with every few requests and must be fresh:
SIDCC__Secure-1PSIDCC__Secure-3PSIDCC__Secure-1PSIDTS__Secure-3PSIDTSWorking Workaround
Direct API calls work when using the exact headers copied from a successful Chrome request (e.g. when creating a playlist manually while logged into the YouTube Music account) :
Suggested Investigation Areas
_usuffix may need to be implementedHow to Reproduce
ytmusicapiytmusic.search("test")→ ✅ytmusic.create_playlist("Test")→ ❌ 401@tschamp31 commented on GitHub (Dec 31, 2025):
EDIT: I was wrong, upon further review. Browser AUTH works it's that the library call structure requires one iteration of a continuation upon initial call. It does not provide song list off the bat as it appears it use to.
@ryansc0tt commented on GitHub (Dec 31, 2025):
A humble note here that corresponds with recent comments: I switched my script for fetching (then updating) playlists to browser auth a couple of weeks ago. Running it again a couple of days ago,
get_library_playlists()requests were returning no results. I haven't debugged at all, but manually refreshing the headers (via Firefox 164.0.1) resolved the issue.@tschamp31 commented on GitHub (Jan 1, 2026):
That's actually a good sanity check as it seems that the web behavior is that it will trigger a reloadContinuationToken + cookie change to minimize automated scraping.
@tschamp31 commented on GitHub (Jan 3, 2026):
I have great news, so it appears they just depreciated the endpoint for either the APIKey or UserAgent or Payload, not sure which but modifying the existing code to just simply utilize TVHTML, client version 7, and a useragent that is WEBTV based allowed for oauth to work again for the endpoint. Main issue is now the parser needs to be updated to allow for tvRender paths 😂
@sgvictorino commented on GitHub (Jan 3, 2026):
@tschamp31 see https://github.com/sigma67/ytmusicapi/issues/813#issuecomment-3359695835
@blastbeng commented on GitHub (Jan 22, 2026):
I am having the same issue, i was using ytmusic api in my own project: https://github.com/blastbeng/spotdl-ytm-service
As a workaround for now i am using yubal, looks promising https://github.com/guillevc/yubal, but i can't automatize it.
Maybe we can try to debug yubal code and understand where is the problem in ytmusicapi?
@foobarth commented on GitHub (Jan 26, 2026):
Sadly it seems browser cookie authentication is no longer a viable workaround as it lasts only a few hours. For me, at least. Google is trying really hard to sabotage free software used by paying customers.
@sigma67 commented on GitHub (Jan 26, 2026):
Please open a separate issue if you are having issues with browser authentication
@apastel commented on GitHub (Jan 26, 2026):
@blastbeng
The problem isn't in
ytmusicapi. Theyubalproject you linked uses browser authentication/cookies too, not OAuth.@lara-rium commented on GitHub (Feb 8, 2026):
same issue :/ heres the exact print: