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:
/profile/user/wow?namespace=profile-us&locale=en_US&access_token=${accessToken}
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.
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. 
So if I understand you well, until the devs change the GET button to a POST one in their pages, the GUIs are unusable ? 
https://develop.battle.net/documentation/starcraft-2/community-apis
Either this or Blizzard devs bringing back the ability to GET OAuth access tokens, whichever comes first. 
1 Like
seems to be fixed, at least for me
1 Like
YES !
The GUI works again on my side too ! 
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.
4 Likes
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. 
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.
Kudos:
- 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. 
2 Likes
I think he’s our only forum MVP who I really believe deserves the title.
Hi, just to let you know:
To get my access-token for the Authentication Code Flow in Postman, this configuration did not work to me, I had to change the “Client Authentication” option to “Send client credentials in body”, instead of “Send as Basic Auth header”.
Thank you anyway because this screenshot helped me a lot.