API Error: GET method is not allowed

I am also getting this error, this applies to calls directly on develop.battle.net. When I enter my client ID and client secret it doesn’t “log me in” instead I get “GET not allowed”. I tried making a new client with new credentials but the error persists.
Even using my access token (that I have been using in my code without issues) returns a 401 error…

1 Like

The workaround here is to click on the link provide your own token instead of using your credentials to sign in.

To generate a simple access_token using the client_credentials flow one alternative is using the Rested extension for Google Chrome or Mozilla Firefox:

Well, it seems I can’t GET anything anymore as well. :woozy_face:

I’m a complete noob in APIs for my part.
So when accessing one of the legacy API of this page :

Am I supposed to click on provide my own access token, and then paste this ?

    function getSslPage($url, $userAgent)
    $ch = curl_init($url);

    curl_setopt($ch, CURLOPT_USERAGENT, $userAgent);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
    curl_setopt($ch, CURLOPT_HEADER, false);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_REFERER, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
    curl_setopt($ch, CURLOPT_POSTFIELDS, []);

    $result = curl_exec($ch);

    return json_decode($result, true);

    $userAgent = 'Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0';

    $url = "https://eu.battle.net/oauth/token?client_id=XY&client_secret=XY&redirect_uri=XY&scope=wow.profile&grant_type=authorization_code&code=$authcode";

    $data = getSslPage($url, $userAgent);

While filling the first XY with my client ID, the second one with my client secret, and the third one with :

Unfortunately for profile related APIs it is a little more complicated because it requires a valid token generated with the authorization code flow.

This means you need to make all the requests on this documentation

1 Like


Then I hope they will fix this quickly 'cause I’m afraid I don’t have the time for blind trial and error through the documentation. :laughing:

Thanks for your answer regardless.

I guess you can use Postman to get a valid token:

1 Like

Thanks, I’ll consider it if the wait for the fix becomes too long. At least I’ve got an alternative in that case. :slightly_smiling_face:

I just want to thank the API devs for implementing another unannounced change. I was getting bored with everything working all the time.


I was able to fix my code thanks to the information in this thread. For the record: I only saw “400 Bad Request”, I never saw anything about GET being bad all of a sudden. The fix was as simple as changing GET to POST in my C# code, but digging to the right location took a while …

I agree, the communication of this kind of things sure could use some improvement.

Yeah, that turned out to be a mistake on my end. After good night sleep I found out my data fetching implementation was faulty (sending GET requests even when I thought it would POST) and managed to fix it. Thanks!

Fair warning, providing your own access_token doesnt necessarily work either.

E.g., making a request to this endpoint:


with a valid access token results in a 404. Attempting the same from Blizzard’s documentation (by including an access token) also results in a 404.

*Edit: Note, the access token for this endpoint acquired through the authorization code flow.

This might be related to another known issue: 404 from Profile API

I’ve seen a lot of 404 errors recently, they happen often (but not exclusively) for very recent profiles (possibly depending on some privacy settings as well). Interestingly enough when I’ve got a 0404 on an EU profile with an EU region parameter, going for the exact same request with an US region gets an errorless but empty response [ ].

Anyway, if that’s a 0404 just going for another profile ID should get rid of it. It’s different from the 0401 or “GET method not allowed” we get for every request since half a day I think. :slightly_smiling_face:

So if I understand you well, until the devs change the GET button to a POST one in their pages, the GUIs are unusable ? :smiley:


Either this or Blizzard devs bringing back the ability to GET OAuth access tokens, whichever comes first. :man_shrugging:

1 Like

seems to be fixed, at least for me

1 Like


The GUI works again on my side too ! :smiley:

Greetings all,

First, we would like to apologize for the disruption and confusion that some API consumers have experienced over the last 24 hours.

We are able to confirm that there was indeed a change deployed which altered the behavior of the OAuth APIs for the /oauth/token endpoint, which removed support for HTTP GET requests. This change was applied with the best intentions to ensure the best security practices are followed for the Blizzard OAuth APIs, however, we realize that this also negitively impacted a number of consumers. We failed to communicate this change ahead of time, and for that we deeply apologize.

This change hase since been reverted, and requests to /oauth/token using HTTP GET should continue to work as they previously did. Our intention is to once again disable HTTP GET requests to the /oauth/token endpoint at a later date, and we ask consumers to please account for this in your integrations by migrating to using HTTP POST. Please keep an eye out for further communication at a later date regarding migrating.

We would like to extend our thanks to everyone who reported issues, and to everyone who assisted others with debugging & troubleshooting efforts here on the forums and through other channels.

Thank you for all of your feedback, reports, and collaboration.


If it was possible, please then consider changing the GET requests mode from the GUIs (such as this ones) simultaneously, as otherwise it requires third party programs to send the oauth token and knowledge of command lines which will leave some of us wondering for a while.

And most particularly Schiller, who seems always ready to provide some advice. :+1:

For what it’s worth, speaking for myself here, I totally get why the change was made. IIRC the spec always said “use POST” and your change did not deviate from that spec, you simply stopped supporting an unofficial alternative method. If we had all been following the spec, we wouldn’t notice you made any change at all. On my own projects, I had some code to fix, but at work I followed the spec 100% and didn’t have any interruption in service. So, technically, the change should’ve been harmless, and indeed been an improvement since the method change could make things more secure in regards to request logs, etc.

However, lots of folks were using GET requests, as evidenced by this thread, as well as your own documentation examples. It would have been nice if you noticed this in your logs, ideally before, but especially after, this change. I think we could’ve supported this change with a minimum of moaning about it if we were given advance notice.

As an API consumer, here’s my feedback for this incident.


  • The backend change simply followed your existing spec.
  • The purpose of the change was in service of security.
  • When your change caused issues, you reverted it within 24-ish hours.
  • You posted a reply in the forums addressing our issues and stating your intentions.

Opportunities for improvement:

  • Before removing functionality (even for good reason), review current usage, especially for components which are used by everyone (authentication/tokens).
  • Announce breaking API changes ahead of time with a future date for when it goes live. Obviously, if there’s a serious security breach, it may be prudent to patch first and notify next, but I don’t think this change qualifies.

Sounds good. I think a lot of us are already ready for it, after this incident. :wink:

1 Like

I think he’s our only forum MVP who I really believe deserves the title.