Player Profile API

Would be possible to share in this API some internal player id and enable to call this API through this player ID? The problem with the player name field is that players change the names time to time and then it is not possible to link old and new profile, so it will duplicate the player.

I think it's a good idea to also allow for player ID

Besides playerID I would like to see fields below, if possible:

Ratings (at least daily and 960daily)

Timeout ratio

Last idea - I need to get number of current matches of the player. I can do it through .games API, but I dont need all the details, just number, so it is not effective to load full list of games during each update.

1) would be possible to add number of matches to player API?
2) or is there way to call games API, but just count the array without reading full list?

Our internal ID structure is liable to change in the future, and so I was resisting sharing it. But I see your point and it makes a lot of sense. We will add these IDs to the Player Profile this week. When and if these IDs change, we will need to do so in a backwards-compatible manner and so you should know that these IDs can be used forever and will always point to the correct person, but they may not reflect the "correct" ID format in the future. Once we make this change, player accounts created after that change will not have IDs in this format. We will be certain to announce it here.

We will be adding ratings and other game-related player data to the upcoming Stats endpoints. The Player Profile is specifically designed to be independent of game play. Since we are designing these endpoints now, are there other elements that you think are essential?

Team matches and tournaments endpoints will be added for players at the same time we create the endpoints for the matches and tournaments. We are unlikely to create a "count only" endpoint, but these player-specific endpoints will be very brief — probably just a list of the tournament/match URLs. Quick to load and count.

I have just found one more important attribute of player, which is missing now.

player status - in order to see that the player's account has been closed

That's a good idea. Would it be useful to see if the player is a premium member, or even more granular like whether they are gold/platinum/diamond/staff? So a "status" element might have a value of either:

• closed, active
• closed, basic, premium
• closed, basic, gold, platinum, diamond, staff

What's useful to you?

At this moment I dont see need to see futher statuses than closed or active. But maybe sby else will found some function fot this.

What can be usefull for example for some league admins is reason of closure. If it was voluntarily, misbehivour or cheating.

I noticed that from today the Player api returns in the coutry URI link instead of just country code, so my script failed. Is it permanent change?

Sorry, I did not catch your post here! Yes, this is a permanent change. In the RFC Countries post, I mentioned "The Player Profile data format will be updated so that the "country" field is a URL pointing to this endpoint."

In the future, I will be more careful to announce such breaking changes more clearly.

Thanks. I have already updated my script.

BTW: i run now automatically update of 200 players each hour which I got from country member list .. So you can check if it couses any issues.

I'd like to post one more vote in support of this idea.  Perhaps endpoint like this:

https://api.chess.com/pub/player_id/{number}

For example, https://api.chess.com/pub/player_id/41 would produce the same data as https://api.chess.com/pub/player/erik

Also, player IDs should be included in the game data. Right now, such data is likely to become stale whenever either of the players changes the username, and requires a repeated retrieval. And I bet you get enough traffic as is, right?

Another possible use for player ID: the https://api.chess.com/pub/country/{XX}/players API can produce huge volume of data; having an alternate endpoint returning IDs (perhaps in hex) rather than usernames might reduce the volume.

Thanks for the suggestions, @LegoPirateSenior — they are certainly accurate. We are reluctant to put more emphasis on the current IDs because they will be deprecated soon after v2 can be shut off. These IDs are sequential and numeric, which imposes certain limiting factors on our ability to scale our backend services. Placing the IDs in the URLs would require us to support the IDs for longer than we would like.

Once we can remove v2 compatibility from our system and upgrade the IDs, then endpoints like what you describe might be quite useful. However, the likely candidate for replacing the numeric IDs is UUIDs, which would not be as slim as usernames and numeric IDs.