[GH-ISSUE #676] 400 Bad Request error when using oauth, but browser authentication works

kerem commented

2026-02-27 23:00:50 +03:00

Owner

Originally created by @AntitrustEnthusiast on GitHub (Nov 9, 2024).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/676

Describe the bug
the ytmusic.search() command is throwing a HTTP 400: Bad Request error with the message Request contains an invalid argument, but only when using oauth. Browser authentication works fine.

Using ytmusicapi version 1.8.2

To Reproduce
Steps to reproduce the behavior:

run ytmusicapi oauth as documented in setup
Minimal script example:

from ytmusicapi import YTMusic

conn = YTMusic("oauth.json")
search_result = conn.search(f"It's beginning to look a lot like Christmas")

Result:

Traceback (most recent call last):
  File "C:\dev\ytmusic\test.py", line 4, in <module>
    search_result = conn.search(f"It's beginning to look a lot like Christmas")
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\dev\ytmusic\venv\Lib\site-packages\ytmusicapi\mixins\search.py", line 183, in search
    response = self._send_request(endpoint, body)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\dev\ytmusic\venv\Lib\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.

Additional context
I've been using it for quite a while without issue, but today it stopped working, seemingly at random. Switching to browser auth has temporarily fixed it for my workflow.

Deleting oauth.json and redoing the authentication flow didn't work either.

Originally created by @AntitrustEnthusiast on GitHub (Nov 9, 2024). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/676 **Describe the bug** the `ytmusic.search()` command is throwing a `HTTP 400: Bad Request` error with the message `Request contains an invalid argument`, but only when using oauth. Browser authentication works fine. Using `ytmusicapi` version 1.8.2 **To Reproduce** Steps to reproduce the behavior: 1. run `ytmusicapi oauth` as documented in setup 2. Minimal script example: ```python from ytmusicapi import YTMusic conn = YTMusic("oauth.json") search_result = conn.search(f"It's beginning to look a lot like Christmas") ``` Result: ``` Traceback (most recent call last): File "C:\dev\ytmusic\test.py", line 4, in <module> search_result = conn.search(f"It's beginning to look a lot like Christmas") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\dev\ytmusic\venv\Lib\site-packages\ytmusicapi\mixins\search.py", line 183, in search response = self._send_request(endpoint, body) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\dev\ytmusic\venv\Lib\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. ``` **Additional context** I've been using it for quite a while without issue, but today it stopped working, seemingly at random. Switching to browser auth has temporarily fixed it for my workflow. Deleting `oauth.json` and redoing the authentication flow didn't work either.

kerem

2026-02-27 23:00:50 +03:00

closed this issue
added the
yt-update
label

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@zostay commented on GitHub (Nov 9, 2024):

I too have started getting this, though, I can't get the browser auth to work either.

@zostay commented on GitHub (Nov 9, 2024): I too have started getting this, though, I can't get the browser auth to work either.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@sigma67 commented on GitHub (Nov 9, 2024):

Could you try messing with the headers to see if removing some fixes it? Hard to tell what the issue is without further indication

@sigma67 commented on GitHub (Nov 9, 2024): Could you try messing with the headers to see if removing some fixes it? Hard to tell what the issue is without further indication

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@AntitrustEnthusiast commented on GitHub (Nov 9, 2024):

Hmm, I ran test requests using this code:

from ytmusicapi import YTMusic
conn = YTMusic("oauth.json")
conn.rate_song("A4zBSnMhvI0", "LIKE")

While removing one of these headers each time:

user-agent
accept
accept-encoding
content-type
content-encoding
origin
authorization
X-Goog-Request-Time

All of them except authorization returned the exact same error message: Request contains an invalid argument.

Here's the full error from the API, in case it helps:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "errors": [
      {
        "message": "Request contains an invalid argument.",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT"
  }
}

Also tried removing ?alt=json from the endpoint, no change.

The only one that had a different result was removing the authentication header, which returned a You must be signed in to perform this operation. error.

@AntitrustEnthusiast commented on GitHub (Nov 9, 2024): Hmm, I ran test requests using this code: ```python from ytmusicapi import YTMusic conn = YTMusic("oauth.json") conn.rate_song("A4zBSnMhvI0", "LIKE") ``` While removing one of these headers each time: * user-agent * accept * accept-encoding * content-type * content-encoding * origin * authorization * X-Goog-Request-Time All of them except `authorization` returned the exact same error message: `Request contains an invalid argument.` Here's the full error from the API, in case it helps: ```json { "error": { "code": 400, "message": "Request contains an invalid argument.", "errors": [ { "message": "Request contains an invalid argument.", "domain": "global", "reason": "badRequest" } ], "status": "INVALID_ARGUMENT" } } ``` Also tried removing `?alt=json` from the endpoint, no change. The only one that had a different result was removing the `authentication` header, which returned a `You must be signed in to perform this operation.` error.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@rafaeldrrmachado commented on GitHub (Nov 11, 2024):

Does anyone know where the oauth.json file is stored? I can't findi it to try and delete it

@rafaeldrrmachado commented on GitHub (Nov 11, 2024): Does anyone know where the oauth.json file is stored? I can't findi it to try and delete it

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@srajangarg commented on GitHub (Nov 11, 2024):

same issue, commenting for visibility!

guessing its a server side change that break the api

@srajangarg commented on GitHub (Nov 11, 2024): same issue, commenting for visibility! guessing its a server side change that break the api

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@AntitrustEnthusiast commented on GitHub (Nov 12, 2024):

Someone in the linked spotify_to_ytmusic issue mentioned it works for them as Manager of their family plan, but not for their wife and kids (non-managers).

I am in the same situation (non-manager), is everyone else experiencing the issue also a non-manager on a family plan?

@AntitrustEnthusiast commented on GitHub (Nov 12, 2024): Someone in the linked spotify_to_ytmusic issue mentioned it works for them as Manager of their family plan, but not for their wife and kids (non-managers). I am in the same situation (non-manager), is everyone else experiencing the issue also a non-manager on a family plan?

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@hhh4hn commented on GitHub (Nov 12, 2024):

everyone else experiencing the issue also a non-manager on a family plan?

This seems related to what I've noticed: it's working fine for me when using oauth creds for one account that is a primary account of mine, but it does not work on another which is a "brand account" under a second account. I get 400: Bad Request on any call using that brand account.

Edit: on further testing, it seems like my 2nd account (which is under a family plan), whether I use its primary or brand account, fail with this error, so my experience supports @AntitrustEnthusiast hypothesis.

@hhh4hn commented on GitHub (Nov 12, 2024): > everyone else experiencing the issue also a non-manager on a family plan? This seems related to what I've noticed: it's working fine for me when using oauth creds for one account that is a primary account of mine, but it does not work on another which is a "brand account" under a second account. I get `400: Bad Request` on any call using that brand account. **Edit**: on further testing, it seems like my 2nd account (which is under a family plan), whether I use its primary or brand account, fail with this error, so my experience supports @AntitrustEnthusiast hypothesis.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@apastel commented on GitHub (Nov 12, 2024):

everyone else experiencing the issue also a non-manager on a family plan?

My account is the manager of my family plan and I get the 400: Bad Request error when using oauth creds.

@apastel commented on GitHub (Nov 12, 2024): > everyone else experiencing the issue also a non-manager on a family plan? My account **is** the manager of my family plan and I get the `400: Bad Request` error when using oauth creds.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@sabad67 commented on GitHub (Nov 12, 2024):

i am seeing this issue as a manager of a family plan.

@sabad67 commented on GitHub (Nov 12, 2024): i am seeing this issue as a manager of a family plan.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@soreikomori commented on GitHub (Nov 12, 2024):

Same here when calling yt.get_history(). I also tried updating to no avail. Currently on ver. 1.8.2.

@soreikomori commented on GitHub (Nov 12, 2024): Same here when calling yt.get_history(). I also tried updating to no avail. Currently on ver. 1.8.2.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@sigma67 commented on GitHub (Nov 13, 2024):

I doubt this is related to family plans, likely just a coincidence.

I would suspect that something in here broke/needs to be updated due the server-side update: https://github.com/sigma67/ytmusicapi/blob/main/ytmusicapi/helpers.py

I will try comparing our requests with the current requests on the web when I find time. Unfortunately I work a full time job so it might be a few days. I certainly recognize the importance of the issue given the number of reports.

In the meantime, anyone else with the time can perform the same analysis!

@sigma67 commented on GitHub (Nov 13, 2024): I doubt this is related to family plans, likely just a coincidence. I would suspect that something in here broke/needs to be updated due the server-side update: https://github.com/sigma67/ytmusicapi/blob/main/ytmusicapi/helpers.py I will try comparing our requests with the current requests on the web when I find time. Unfortunately I work a full time job so it might be a few days. I certainly recognize the importance of the issue given the number of reports. In the meantime, anyone else with the time can perform the same analysis!

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@secnonsense commented on GitHub (Nov 13, 2024):

I have an individual plan and am also seeing this error. Maybe the issue is due to having multiple accounts on the plan? In my instance I use a branded account instead of my primary gmail.com account. I saw the error using my branded account, however after regenerating my oauth.json using my gmail.com account everything worked as expected.

@secnonsense commented on GitHub (Nov 13, 2024): I have an individual plan and am also seeing this error. Maybe the issue is due to having multiple accounts on the plan? In my instance I use a branded account instead of my primary gmail.com account. I saw the error using my branded account, however after regenerating my oauth.json using my gmail.com account everything worked as expected.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@Batwam commented on GitHub (Nov 14, 2024):

I'm also getting this HTTP 400 error for the last few days. Glad to see I'm not alone. I tried to generate oauth.json from 2 separate accounts and both of them fail.

@Batwam commented on GitHub (Nov 14, 2024): I'm also getting this HTTP 400 error for the last few days. Glad to see I'm not alone. I tried to generate oauth.json from 2 separate accounts and both of them fail.

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@parthcooks commented on GitHub (Nov 14, 2024):

it was working for me till yesterday , today even im facing this issue , sigma67 is there any fix for this?

@parthcooks commented on GitHub (Nov 14, 2024): it was working for me till yesterday , today even im facing this issue , sigma67 is there any fix for this?

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@apastel commented on GitHub (Nov 14, 2024):

We're all well aware that the issue is happening, now it's time for the open-source community to do its thing and come together and fix it. If you scroll up and read @sigma67's message, you'll see they are busy and some suggestions about where to look in the meantime. It's probably some header or something that changed on one of the requests in the oauth flow. I tried looking at the API docs for OAuth 2.0 for TV and Limited-Input Device Applications but nothing stuck out as being different. Also tried going through the oauth flow in the browser and looking at the requests/responses to see if there's anything that looks like one of the requests in the helpers.py file, but I might just be looking in the wrong place. The properties in oauth.json itself seem to match exactly what's expected according to that API document...

@apastel commented on GitHub (Nov 14, 2024): We're all well aware that the issue is happening, now it's time for the open-source community to do its thing and come together and fix it. If you **scroll up** and read @sigma67's message, you'll see they are busy and some suggestions about where to look in the meantime. It's probably some header or something that changed on one of the requests in the oauth flow. I tried looking at the API docs for [OAuth 2.0 for TV and Limited-Input Device Applications ](https://developers.google.com/youtube/v3/guides/auth/devices) but nothing stuck out as being different. Also tried going through the oauth flow in the browser and looking at the requests/responses to see if there's anything that looks like one of the requests in the helpers.py file, but I might just be looking in the wrong place. The properties in `oauth.json` itself seem to match exactly what's expected according to that API document...

kerem commented

2026-02-27 23:00:51 +03:00

Author

Owner

@abetwothree commented on GitHub (Nov 15, 2024):

Seeing same issue. Tried multiple accounts and it all fails locally and on a server. However, it does work locally without an oauth.json file.

@abetwothree commented on GitHub (Nov 15, 2024): Seeing same issue. Tried multiple accounts and it all fails locally and on a server. However, it does work locally without an oauth.json file.

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@apastel commented on GitHub (Nov 15, 2024):

People in different projects are saying that Google is removing OAuth support for YTMusic, and they are switching back to using cookies 😢 The reason it happens for some accounts and not others of course is because of A/B testing (edit: well, global rollout, technically)

https://github.com/KoljaWindeler/ytube_music_player/issues/367#issuecomment-2472397147
https://github.com/music-assistant/hass-music-assistant/issues/3138#issuecomment-2471316657
https://github.com/yt-dlp/yt-dlp/issues/11462#issuecomment-2471087887

I haven't seen anything conclusive stating this to be true, but it seems like developers of different projects are seeing the writing on the wall, which points toward bye-bye for OAuth. Let's hope that's not the case...I'm not sure how to determine if it is or not.

@apastel commented on GitHub (Nov 15, 2024): People in different projects are saying that Google is removing OAuth support for YTMusic, and they are switching back to using cookies :cry: The reason it happens for some accounts and not others of course is because of A/B testing (edit: well, global rollout, technically) https://github.com/KoljaWindeler/ytube_music_player/issues/367#issuecomment-2472397147 https://github.com/music-assistant/hass-music-assistant/issues/3138#issuecomment-2471316657 https://github.com/yt-dlp/yt-dlp/issues/11462#issuecomment-2471087887 I haven't seen anything conclusive stating this to be true, but it seems like developers of different projects are seeing the writing on the wall, which points toward bye-bye for OAuth. Let's hope that's not the case...I'm not sure how to determine if it is or not.

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@jurgenweber commented on GitHub (Nov 15, 2024):

The reason it happens for some accounts and not others of course is because of A/B testing.

I agree, either A/B Testing or the nature of the global rollout.

removing OAuth just seems like a direct stab at disabling these sorts of integrations.

@jurgenweber commented on GitHub (Nov 15, 2024): > The reason it happens for some accounts and not others of course is because of A/B testing. I agree, either A/B Testing or the nature of the global rollout. removing OAuth just seems like a direct stab at disabling these sorts of integrations.

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@sigma67 commented on GitHub (Nov 15, 2024):

As expected this is a widespread issue affecting all third-party oauth clients: https://github.com/yt-dlp/yt-dlp/issues/11462

Is anyone facing issues with browser-based auth also? Seems to be working ok for me

@sigma67 commented on GitHub (Nov 15, 2024): As expected this is a widespread issue affecting all third-party oauth clients: https://github.com/yt-dlp/yt-dlp/issues/11462 Is anyone facing issues with browser-based auth also? Seems to be working ok for me

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@srajangarg commented on GitHub (Nov 15, 2024):

As expected this is a widespread issue affecting all third-party oauth clients: yt-dlp/yt-dlp#11462

Is anyone facing issues with browser-based auth also? Seems to be working ok for me

@sigma67 confirming that browser-based auth also works for me

@srajangarg commented on GitHub (Nov 15, 2024): > As expected this is a widespread issue affecting all third-party oauth clients: [yt-dlp/yt-dlp#11462](https://github.com/yt-dlp/yt-dlp/issues/11462) > > Is anyone facing issues with browser-based auth also? Seems to be working ok for me @sigma67 confirming that browser-based auth also works for me

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@luisignaciocc commented on GitHub (Nov 17, 2024):

For me, browser-based authentication doesn't work either. Using the get_history() (browseId: "FEmusic_history") on https://github.com/luisignaciocc/ytmusic-scrobbler-web/issues/11

@luisignaciocc commented on GitHub (Nov 17, 2024): For me, browser-based authentication doesn't work either. Using the get_history() (browseId: "FEmusic_history") on https://github.com/luisignaciocc/ytmusic-scrobbler-web/issues/11

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@Batwam commented on GitHub (Nov 18, 2024):

same here, works with browser authentications, the instructions are here: https://ytmusicapi.readthedocs.io/en/stable/setup/browser.html

Is this authentication method going to have to be renewed regularly?

@Batwam commented on GitHub (Nov 18, 2024): same here, works with browser authentications, the instructions are here: https://ytmusicapi.readthedocs.io/en/stable/setup/browser.html Is this authentication method going to have to be renewed regularly?

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@sigma67 commented on GitHub (Nov 18, 2024):

Common advice to make long-lasting cookies is to create them using the browser's in-private session. This avoids accidentally messing with the session during your regular browsing activity

The cookies last quite long in my experience

@sigma67 commented on GitHub (Nov 18, 2024): Common advice to make long-lasting cookies is to create them using the browser's in-private session. This avoids accidentally messing with the session during your regular browsing activity The cookies last quite long in my experience

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@Batwam commented on GitHub (Nov 18, 2024):

that's good to know, thanks

@Batwam commented on GitHub (Nov 18, 2024): that's good to know, thanks

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@Hengen42 commented on GitHub (Nov 18, 2024):

I couldn't manage to get cookies in the brave browser. I keep getting a 401 error.

@Hengen42 commented on GitHub (Nov 18, 2024): I couldn't manage to get cookies in the brave browser. I keep getting a 401 error.

kerem commented

2026-02-27 23:00:52 +03:00

Author

Owner

@Hengen42 commented on GitHub (Nov 18, 2024):

"te": "trailers\u001a"

I solved the issue by removing this code from the browser.json file. However, I've been struggling with it for hours. It was so silly.
Example: (where there was a space there was the usual "te": "trailers\u001a".)

{
    "accept": "",
    "accept-encoding": "",
    "accept-language": "",
    "authorization": "",
    "connection": "",
    "content-encoding": "",
    "content-type": "",
    "cookie": "",
    "origin": "",
    "priority": "",
    "referer": "",

    "user-agent": "",
    "x-goog-authuser": "",
    "x-goog-visitor-id": "",
    "x-kl-ajax-request": "",
    "x-origin": "",
    "x-youtube-bootstrap-logged-in": "",
    "x-youtube-client-name": "",
    "x-youtube-client-version": ""
}

@Hengen42 commented on GitHub (Nov 18, 2024): "te": "trailers\u001a" I solved the issue by removing this code from the browser.json file. However, I've been struggling with it for hours. It was so silly. Example: (where there was a space there was the usual "te": "trailers\u001a".) ``` { "accept": "", "accept-encoding": "", "accept-language": "", "authorization": "", "connection": "", "content-encoding": "", "content-type": "", "cookie": "", "origin": "", "priority": "", "referer": "", "user-agent": "", "x-goog-authuser": "", "x-goog-visitor-id": "", "x-kl-ajax-request": "", "x-origin": "", "x-youtube-bootstrap-logged-in": "", "x-youtube-client-name": "", "x-youtube-client-version": "" } ```

Rows
Columns

[GH-ISSUE #676] 400 Bad Request error when using oauth, but browser authentication works #450