It's what GOG's own website uses, so, unreliable or not, it's actually supplying the prices you're seeing when you purchase things or look at product pages.

Thanks. I indeed see them using the multiple ID calls for things like "buy series" and "users also bought". Pretty hopeful!

I didn't keep track, but I think it happened every crawl, which is more than 1 in 100 requests.

FWIW, I haven't encountered this at all in my API calls so far (and added explicit logging for it, so it wouldn't escape my attention).

For anyone using the v2 games API, GOG is changing certain fields. The changes of the last two days have been:
* _links/iconSquare has been removed after being empty for a while
* _links/boxArtImage may be missing instead of being empty
* series may be missing instead of being some falsy value. I don't remember what is was previously, probably empty object, but from the code it could also have been null or false.

It was null on some entries at least. Sigh, hope it doesn't turn into a major change... API payloads aren't expected to change without a revision in theory :/.

Edit: And indeed my scan script failed because of missing series fields now, lovely. Seems like _links/store can also be missing now. Equally lovely. It makes for a lighter payload at least, but the change is a bit disruptive.

I noticed this started giving 404, while before I think it worked:

https://content-system.gog.com/products/1342464301/os/linux/builds?generation=2

I've hit an interesting issue and wonder if anybody noticed that as well. Sometime (likely) recently GOG.com catalog.gog.com results started to be limited to 10 000, regardless of parameters. E.g. top level menu STORE > Browse all games... will show "Showing 10000 games of 11129 games in total" when no filter is set and 209 pages of results. 208 * 48 = 9 984.

In my project (github.com/arelate/vangogh) I'm fetching fresh catalog data regularly (replacing existing data) and rely on it for several subsequent decisions (e.g. what Steam data to update). Previously - the data was paginated, but not limited. Now, there's 1 129 products that are missing when you get all catalog pages through catalog.gog.com/v1/catalog API - off top of my head I can't find Metal Eden and Skyblivion in catalog pages data.

Any chance anybody noticed that as well? I've started to think about mitigation strategies, but perhaps there's a cleaner solution for this?

I think the common way to deal with this is reverse sorting on something stable, and then gathering from both ends. (Which will work until 20,000 products, and then after that you need to find some mutually exclusive filters.)

Personally these type of issues are the reason that for gamesieve I'm sticking to the officially supported API - api.gog.com/v2/games - as much as possible (added benefit for data gathering: that goes up to limit=200). If after gathering you reduce the output of that on releasestatus != 'unavailable', you'll come very close to the catalog API output, with the only difference being alternative products for countries where the main product is banned.

Looks like gogdb also uses catalog.gog.com (@yepoleb: your moreinfo page still says /ajax/filtered), so yepoleb must already have a solution for this basic issue. search_after might be the key?

edit: that's indeed it.

Perfect - thank you gogtrial34987 for the solution and jpolgesek for the confirmation!

Thanks for the confirmation!

Can I read that as catalog.gog.com being officially sanctioned for external use? Any usage limits? (It'd be really good to have some sort of official page somewhere stating this type of thing.)

For posterity (since it took me a bit to figure that out) - Catalog API parameter name is "searchAfter" (and not "search_after" which is a value in gogdb code for a pagination method).