Switching to a 64-bit ID?
Noobie questions and real time PGNs

UUIDs. The current sequential IDs were dead-simple to setup a decade ago, but require that we insert data only on a limited number of databases. UUIDs will allow us to have more of our databases write data, improving performance and allowing greater scale.

The games are listed in the order that they were finished. Their IDs are created in the order that they are started. Therefore, you should not expect that games are listed in the order of their IDs.
...
Games will not be available by ID in the short term. Their IDs are changing, partly because there are just too many of them! Once the new ID system is in place, then games will be available in the API individually by ID. Expect that late this year or early 2019.
Edit: per @bcurtis' later post but not my memory when I wrote this post, the order of games is documented.
For the first, that's not in the documentation and I'm pretty sure the order of *completion* is reverse chronological order and is nearly-but-not-quite reliable, i.e. I have found exceptions. Possibly with some time hunting about I could find the data that was out of order, but not today; I've come down with 'flu or something.
I, like @MGleason very much hope you do not break old game links. An expansion from 32bit to 64bit obviously doesn't have to ... so please preserve the old game IDs and links.
(It's trouble enough that player_id can't be used for a lookup and is not promised even to be provided ... "Please look at xyz." "There is no xzy." Since re-use of old names is allowed it gets even more confusing. But off topic for this thread.)

Sorry, didn't read far enough. UUIDs and the old IDs won't look the same, but shouldn't collide either.
Whatever solution you choose is up to you, but pre-allocation of blocks of IDs has been done other times and places. I've no objection to UUIDs though.

The game-endpoints documentation states "in ascending game-end-time order." If you see that's not the case, then that's a bug we should address.
Old IDs will forward to new equivalents on the website. In the API, games will only be referred to by the new ID. However, since many of you need to link old API requests of today to new results after the ID switch, we will provide a mechanism for that. Don't worry, we are putting a lot of effort into backwards compatibility — that's the promise of an API, after all.
In the meantime, I'll get to work on a chicken-soup endpoint. Hopefully, no bugs. Yuck. Hope you get over that flu soon.

Thanks, @bcurtis. I'll try to remember which user it was I wanted a particular set of games from.
If you document "ascending" then that's probably enough to explain actually now I think about it for 2s ... I work back per-month mentioned in the archives list until I have "enough" games for whatever value of "enough" I've specified. So when I hit the file where the games I wanted were at the end (latest) and I didn't want the first (earliest) I would have got the "wrong" games.
Add my (incorrect) understanding that the games were in descending order and there you have it.
But I'll still see if I can dig up which user it was and examine the original data files.
Who was it I wanted 13 games from?
Thanks for the clarification on the documentation and it's about to be painkiller-and-lights-out here.
Cheers,
Giles

Remembered the username and checked: my hypothesis in post #27 is correct.
I was confused by my own wrong idea about the order of games in the archive files.
As my script now sorts them into the order I want them in, all is well (other then me personally temporarily!) and will remain so.
Wouldn't mind that chicken soup endpoint!
The games are listed in the order that they were finished. Their IDs are created in the order that they are started. Therefore, you should not expect that games are listed in the order of their IDs.
Computers are not people. You cannot look up their games. This is mostly because if we allowed that, then the archives would need to be blocked out by day rather than by month, since the computers play millions of games per month. This would make the API very awkward for everyone in order to accommodate a use that does not help our players.
You are using the endpoints for game archives. These are all games that are finished. If you want PGNs that are updated as the game is played, then you need to use the "current games" endpoint. For example: https://api.chess.com/pub/player/bronsteinpawn/games
Real time game information for live chess play is not currently available, and cannot be scraped as HTML.
Games will not be available by ID in the short term. Their IDs are changing, partly because there are just too many of them! Once the new ID system is in place, then games will be available in the API individually by ID. Expect that late this year or early 2019.