I'm sort of maintaining a fork of gogrepo while woolly is away. Trying to use the API to cut down on the connections and required wait time to not get temporarily blocked for looking like a DDOS attack. I really don't want to have to maintain a separate version with Galaxy installer support or write some horrendous frankenstein hybrid that checks the account API if Galaxy installers are selected.

You still have to be careful though, you can also get a temporary block by over-stressing the APIs - it happened to me twice, albeit it's rather rare. What you'll run across more often is the APIs returning HTTP error codes back at you whenever you've exceeded the GOGBear police speed limit.

I found this interesting github page:
https://github.com/toddmotto/public-apis

I'd contribute to the project by trying to add the documentation of the GOG API but instead of doing it by adding an issue to the repository, it has to be done by forking and pull requests which is something I'm not familiar with. If someone could get the contributors of the list to add the documentation it would be pretty darn nice.

Just saying.

The site is specifically for public APIs. I don't think the GOG API fits that definition, as it's not meant to be used by people outside of CD Projekt. This unofficial documentation does not count, because it's written by a third party.

iirc GOG openly stated that they are fine with people using the API (assuming they can figure it out) and develop their own client. They just don't make any promises not break the API since it is still in development.

Apart from that, everything else points in the direction of it being a closed API. Most importantly that you can't request your own OAuth credentials and have to use the ones from the official client, which is not how OAuth is supposed to work. Being able to request your own key is essential to a public API. Check out every other site on that list and you see the difference in openness.

What did GOG say about it? Since they claimed indeed that they are supportive of community clients, how are they supposed to work?

I've been wanting to get in contact with them for while, but never got around to it. "Supportive" is probably too strong, I interpreted their stance as basically "just do what you want, we don't care". So they most likely didn't think about community clients when designing the auth flow. You could try requesting access to their dev portal, I may give it a try as well, if I finally find the motivation to write an email.

Late update: No developer account / API keys for non-partners.

I've also pushed a few minor correction and finally an update of the authentication flow, which should be live already.

Yeah, that's not nice of them. One way to deal with it, is to create a formal community FOSS project that will become an official developer partner.

might be worth pointing out in the documentation that the former method returns all owned ids, including bundle ids (game_type == pack) and DLCs.
While the latter only returns individual games (as listed on the game shelf), no packs, no DLCs


this gives access to the xdelta patches that GOG introduced in recent Galaxy builds

Could you add these changes yourself? I'm already working on two other GOG projects and want to focus on them. Source is at https://github.com/Yepoleb/gogapidocs

I think it's been a long time since they've claimed that and we haven't heard them reinforce their earlier claims of supporting community made clients in a long time now. I think it is safe to say that they no longer entertain the idea of supporting community made clients nor having a publicly documented API for developers to use, and that they will restrict any APIs they do have to developers that they sign contracts to partner with at their discretion.

That's what all visible evidence appears to suggest from outside of GOG looking in anyway. If it isn't the case then it would be nice for them to be transparent about it and issue a public statement sometime soon to indicate if they are indeed dedicated to fulfilling their promise of providing a publicly documented API that 3rd parties can use for making their own clients.

IMHO, they're more likely to just maintain complete radio silence if they've had a change of heart on this and all they would have to say are things that would be of grave disappointment to the community by renegging on their prior commitments.

i'll give it a try. time to learn how to ... sphinx :)