I currently use the the MSA Tournament page for an member’s ID to pick up the most current regular rating and date of the tournament from an automated script. Is there an easy way to do this for the new system? Out of luck for now?
e.g.
curl --ssl-no-revoke -s US Chess MSA - Member Details (Tournament History) > tinfo.txt
ugg discord formatting …
curl --ssl-no-revoke -s https ://www.uschess.org/msa/MbrDtlTnmtHst.php?12000880
That kind of webscraping is one of the things we’re hoping to discourage, by offering an API that will get you a more direct (less cluttered) response that can be built in to pairing programs, etc.
To be honest, I haven’t tried to find a way to pull up that information yet, so I don’t know what the equivalent URL would be to bring up a list of a player’s most recent events to find their current rating, or if it’s even possible, but in the long term we’d much rather give programmers a more structured way to get to that kind of information, possibly with a separate URL so we can do things like load balancing and rate limiting.
I did go ahead and open a support ticket on this, just to get it on the list of things to do.
It is currently quite possible for a handful of people sending in requests like that to tie up MSA so that it basically stops functioning. It happened again last weekend.
If you bring up a player’s page on MUIR then click on ‘more’ next to ‘tournaments’ on the right-hand side, you get this page:
I noticed that & my guess is I need an in-between tool to do a true screen actions/scrapes versus the simple curl to get the page source query directly.
I note that the start and end for all of these tournaments is October 2, 2025; I hope that’s a loading issue?
Apparently it is not too hard to replace the curl with a pretty simple python/selenium script to simulate the more button press. I might try it out for my next tournament if the api is not available.
Yeah, the beta system was last refreshed on October 2nd. When MUIR goes live, it will have all events submitted ahead of the cutoff for TD/A, which is 9PM on Wednesday, October 29th.
I don’t have a timeline for the API, it won’t be out ahead of launch, that much I’m sure of.
Once the API is released, there will be a process for signing up for an API key and we will give TDs, affiliates and software developers some time to update their systems before we start doing severe rate limiting on access to player data through webscraping the MUIR web pages.
The ‘thin client’ and related interfaces will continue to be available during the transition to MUIR, but while they should continue to provide current membership information they will not have any updated tournament or ratings information after October 29th, and we hope to be able to remove these systems from service in early 2026.
It seems the API already exists. Here’s how to get the latest rating info for a player by USCF ID:
curl https://beta-ratings-api.uschess.org/api/v1/members/12641216 | jq
and the JSON response:
{
"fideId": "2016192",
"gender": "Male",
"fideTitles": "G",
"lastChangedDate": "2025-10-07",
"rank": 1,
"stateRank": 1,
"ratings": [
{
"rating": 2874,
"ratingSystem": "OverTheBoardRegular",
"gamesPlayed": 1566,
"isProvisional": false,
"floor": 2200
},
{
"rating": 2774,
"ratingSystem": "OverTheBoardQuick",
"gamesPlayed": 436,
"isProvisional": false,
"floor": 2200
},
{
"rating": 2959,
"ratingSystem": "OverTheBoardBlitz",
"gamesPlayed": 180,
"isProvisional": false,
"floor": 2100
},
{
"rating": 2747,
"ratingSystem": "OnlineRegular",
"gamesPlayed": 21,
"isProvisional": true,
"floor": 100
},
{
"ratingSystem": "OnlineQuick",
"gamesPlayed": 0,
"isProvisional": true
},
{
"ratingSystem": "OnlineBlitz",
"gamesPlayed": 0,
"isProvisional": true
}
],
"id": "12641216",
"firstName": "HIKARU",
"lastName": "NAKAMURA",
"stateRep": "NY",
"uscfStateCode": "NY",
"expirationDate": "2030-12-31",
"fideCountry": "USA",
"status": "Active"
}
Please don’t tinker with those, they have not been field-hardened yet and may allow access to non-public data.
I’ve reported this to the Leago developers.
For what it’s worth, I didn’t go out of my way to find something hidden and try to expose it. That’s just how the new site works. The frontend code in the browser is using that API. It’s totally understood if it’s considered unsupported for use outside of the site itself, though. I appreciate that clarification.
Each ratingSystem should have should have it’s own date.
Not sure what rank/stateRank Rank means – perhaps that needs moved under each rating, too.
I know, and I pointed that out to the developers. Anybody with some tech knowledge who was on the beta site could have figured that out.
The disadvantage with using API’s for internal data usage is that unless they’re locked down they’re also available to others.
Rank and state rank are things present on the current MSA system that are part of MUIR.
In the past, a change in any rating when generating a ratings list triggers generated creating a rating supplement record for all ratings systems, even if the others don’t change.
The way FIDE does it has some advantages, whey they publish a new FRL, it includes the number of games the player has in the current month. With rerates, someone’s rating can change even if they haven’t played any games in the last month, though.
ok What do rank/state rank mean? Regular OtB? and is it actual current or just for the current published supplement.
I guess I really don’t understand re-rates. I figured each rating system does it own thing when needed without the other systems. I just pick the pre/post ratings from the tournaments that someone played in and use the date associated with the tournament. What appears to be the new api isn’t really doing what I do on the old system given a id - chronologically pick post ratings by system (like the raw data behind the static ratings graph does) – Right now I only inspect the first page for the current regular rating change and end date which is good enough for my purposes (not perfect). – Despite saying I use the official month ratings I often get that is not their rating - so I post official and Latest with date and if someone asks during check in the info is already there - end of month tournaments especially can have quite a few significant deltas.
Official ratings are just a snapshot in time, what we know about your rating at that point. When we decide to take that snapshot is a policy issue.
The point of rerating is to show what the ratings are once any corrections or tardy events are taken into account.
Suppose you have a rating of 1620 and play in two events. You do really well in the first and meh in the second, but the second one gets submitted quickly while the first one gets delayed for a week or two.
So the ratings flow is:1620 followed by the meh event, so let’s say it goes up to 1621.
Then the great event comes in. Now that 1620 rating goes to 1700 (you had a great day!). So what happens to the meh event? When we rerate, your rating goes 1620 to 1700 then the meh event drops it back to say 1692. So your latest rating after all 3 events are rerated is 1692.
The current architecture is that browser/client side is accessing the server with API (RESTFUL API probably), so even they locked down (not sure how), developer will be able to access those API by login with their US Chess TD login and access it.
You appear to know more about APIs than I do, but I’ve been mostly a database guy since about 1992.
ok – that is what I thought for out of order types & then there is the correction to something older.
In either case they should ripple to anything impacted by that change (perhaps by just making sure there are changes to pre-tournament ratings before flagging it for a re-rate which doesn’t change anything) – Bottom line for me is I like to see the date that each rating categories was last rated (I understand there are some extreme cases where this fails, but not a show stopper and they may never happen)
As Leago will need to re-engineer how the rating supplements are generated fairly quickly in order to generate the December Ratings Lists in 3 weeks, there’s a short window of opportunity for US Chess to rethink the process.