Forum

I have not obtained any results in my querys: https://api.chess.com/pub/player/Algoritmo-DCP/games https://api.chess.com/pub/club/team-spain/members https://api.chess.com/pub/invented123456

I saw some news about v2 sunset on 30th September. I would appreciate if at least basic club matches resources are available prior the sunset as my previous version of tools are running on v2 screenscraping and I was not successful with development of v3, so I postponed it till API availability. So if v2 is down and club APIs not available, I would need to try screenscrap v3, which I wanted to avoid. Thanks for your understanding and help :-)

To better conform with the upcoming player ratings groups, we need to change some of the standardized values in the games endpoints. time_class : all daily chess games will use the term "daily" rather than an indication of the number of days per turn. Other livechess time classes will be unchanged. time_control : a new field will be added with specific timing indication. The values here will be the same as you see in the one-click "start a game" shortcuts in the navbar, plus any custom time control values that are set in livechess games. Here is where the daily chess days-per-turn value will go. rules : this will cover the same set of rules variants, but will use our internal notation (lowercase, one-word no spaces). Notably, "Standard Chess" will become "chess." We expect these changes to be live this week.

This Request For Comments covers a new per-player endpoint to provide current playing stats for each game type, and changes to the data values for games-related endpoints. Historical rating data will be obtainable from the game archives. Please note: These endpoints should provide the same data as the website stats pages, but some aspects of these API stats will be coded from scratch; as such, we want to treat any difference as a bug and would appreciate reports covering such cases.   /pub/player/{username}/stats Each timeclass and rules variant will have a "stats" block of approximately the same structure, identified by a key in the format of "<rules>_<timeclass>". This is always true; all livechess variants are in the "blitz" timeclass, and so even though it seems redundant these will be named like "bughouse_blitz" and "chess960_blitz". In addition, we will be using the website timeclass names: "rapid" in place of "standard," and "bullet" in place of "lightning." The games endpoints will be updated to reflect this (see note below). Therefore the player-stats DTO is a collection of named stats DTOs, like so: { "chess_daily":{ /* stats block */ }, "chess960_rapid":{ /* stats block */ }, "bughouse_blitz":{ /* stats block */ } } Timeclass options are: daily, rapid (previously "standard"), blitz, bullet (previously "lightning"). Rules options are: chess, chess960, crazyhouse, bughouse, kingofthehill, losers, oddschess, threecheck. Not all combinations are available. Many livechess variants only track the "last" rating info and so their stats blocks will have no "best" or "tournament" blocks. If the player has never been in a tournament, that block is not present. If the player has never won a game, the "best" block is not present. We will only deliver stats blocks for class/rules combinations that the player has actually played — no default entries should be delivered. This means that players who have just registered and not yet played will have an empty stats object. Each stats block contains: { "last":{ "rating":1500, "rd":56.7, "game":"web URL", "date":123456789 }, "best":{ "rating":1500, "game":"web URL", "date":123456789 }, "record":{ "win":1, "loss":2, "draw":3, "time_per_move":56160, // daily time class only, measured in seconds "timeout_percent":23 // daily time class only; note: only past 3 months (same as web UI) }, "tournament":{ "points":1, "count":1, "withdraw":2, "best_finish":12, // only if greater than 3 "finished":[ // only available if the player has placed in top 3 at least once { /* after tournament endpoint: place, tournament link */ } ] } } Breaking Change /pub/player/{username}/games/pub/player/{username}/games/YYYY/MM All game endpoints will have a change to the time_class values, to use the website terms for livechess "rapid" (previously "standard") and "bullet" (previously "lightning").   Does this endpoint get you what's needed for your stats and ratings projects? Are there related data we missed that are essential? If possible, please include specific examples of how you intend to use the data, especially if you request that we change this output in some way.

Would it be possible to somehow show if a player is titled or not? Perhaps even add what their title is? Edit: Perhaps a "player_type": "titled | untitled" could be provided in the https://api.chess.com/pub/player/{username} endpoint. And if they are titled perhaps something -if they are a GM, for example-: "title": "GM"

While I have not received a 429, I am being cautious and limiting my request rate in some small projects of mine. Out of curiosity as well as future reference -if I ever need to handle a 429-, though, is it safe to assume you will be providing a "Retry-after" header? Edit: Sorry, I meant that I have not received a 429. I have edited my question to clear that up.

I cam across this forum post: https://www.chess.com/forum/view/community/chesscom-developer-program-ec I am curious as to whether you still provide this -especially with this beta API. While I will be using heroku for a current project I am working on -which is utilising the PubAPI-, I think it best for it to stay more ... separated from chess.com . But, I ask to see if I might be able to use it for future projects.

We have about 60 players who have more than 250 currently-active Daily Chess games — and 2 players actually have more than 1000! The current API is not well suited for these large lists, but is working very well for the average player (8 currently-playing games). We are looking at limiting the /pub/player/{username}/games list to just the most recently changed 250 games. Even though this list would not be complete for 60 of our players, it would always contain all of their current games in which the other player just moved or performed some other action. The /pub/player/{username}/games/to-move list would still be a complete listing of all games the player needs to make a move in. The game archives endpoints would be unaffected. I am asking the developers here if this limitation for these 60 players would have significant negative impact on their work or plans.

I would like to suggest endpoints for accessing player statistics. Such as: Ratings for the various game types -e.g, Daily, Rapid, Blitz-, and various stats for each game type. So, timeouts for daily games, perhaps Glicko RD, and the percentages of wins, losses, and draws based on colour. Also, would it be possible to get historical ratings in JSON? Maybe adding a "start_rating" and "end_rating" for white and black in games from the "Monthly Archives" endpoint? Edit: Though, thinking about, I guess that last part about adding a start and end rating really is not nessecary. Silly me.

Topic to discuss identified bugs with the APIS.

Hi everyone! I made a notification icon for Polybar. Here is is on GitHub. It simply shows how many games you have to play and it automatically will change color to let you know you have a game to play, and it takes you straight to your next game when you click on it. Hopefully it will make using Chess.com a lot easier for all you Linux users out there!

Hi there, Fairly new to the forum and just playing around to see what is possible.I did notice that while the documentation in the README for the Published-Data API mentions that the JSON returned by a call for Complete Monthly Archives does not conform to the format specified. The documentation mentions that both the white and the black field in each game contain the username of the player, but this is not the case; both the example call and calls to current data return the white and black fields with only 3 fields (rating, @id and result). I might be missing something and I'm also not sure whether this is the correct place to post this (if not, please let me know and I'll (re)move it), but if not, is it possible to amend this?

One needed endpoint, which is not yet in the roadmap, would be for me members with some filtering and sorting criteria. In order to support functionality to find new club players suitable for the team, I would like to search through all members and filter those in specific country or location and sort them based on recent activity timestamp. Do you think that you can have a similar endpoint in the future? It would be a replacement to screenscrap ie this page: https://www.chess.com/members/search?country=40 Thanks.

I see that you offer link to chess.com pictures (ie player avatar). Is it allowed to display pictures from images.chesscomfiles.com on my webpage by calling this external URL?

Do I need to identify myself, when I am calling your API? Or is it sufficient ie to use the parameter "From:"? In some API implementations, developers need to register, will get API key and then they use the key in order to utilize APIs. This gives you the possibility to see utilization of your environment by different apps and blocking them if needed.

Thanks for moving forward with this initiative. I believe that in this world full of developers and open platforms it can provide many interesting ideas and features for users, which are not/can not be done directly at Chess.com. By reading README, I have one generic problem with the sentence below: and by accessing these APIs you agree to not harvest or store the data for offline use in any way I understand that you need to protect data and your know how, but if I would like to offer added value to users, then data has to be stored to some level. For example if I would like to provide additional statistics about club matches, that it is nonsence to call online full match history of the club online through API when manager send the request. Please rediscuss this limitation. Thanks. Petr