Broken endpoint: https://api.chess.com/pub/club/{url-ID}/members

That's my guess and I would have assumed that it should have always been the case, even if it may not have been. The Public API is only supposed to return publicly available data and clubs with private member lists don't fit that definition.

But as I stated, it's not hard to get the active members in a club even with a private list. So the setting isn't really useful in 99% of cases.

If club admins want the member list private the site shouldn't have an easy way to get that list regardless of the setting.

Sure, one can figure out some members of the club had events but admin required privacy seems like the more important consideration. Certainly a better result would be better, rather than an error state.

I see the logic, Martin. What I don't see is any sensible follow through. The endpoint return for a private listing is just so poor. No thought given to the consequences.

And I detest the fact that changes are made without any advance notice. Once again the API spec is wrong because it doesn't reference the privacy setting.

What I don't like is to have to choose to have a private list for my club, or to be able to manage it with my scripts, now that I invested a lot of time to develop them.

I'm not aware of specific work explicitly being done on the API. Some changes are related to other back end processes and where data is being fed from. It's possible this particular issue was related to that and not direct work on API code.

At the moment I'm getting error "404" returned for requests for member lists in clubs with it set as 'private' but if a request is being made for content that's withheld then we should receive "403" I'd have thought?

Why am I suddenly getting a 403 Forbidden error?.
"The 403 Forbidden error means that your server thinks you do not have the required permission to access that particular page. This is usually caused by an issue with file permissions, but could be caused by another problem related to hosting or authentication"

.
If a user of the API receives "404", it tells them very little and they'll probably repeat the request in the hope the problem fixes itself. Remember that a corrupted ednpoint returns "404"! That's the problem I've been having here...

https://www.chess.com/clubs/forum/view/egypt-chess-club-endpoint-corrupted

So if the site's developers could at least ensure the appropriate error status is returned, it would be more helpful and would tell us that we shouldn't make any further requests.

I would have thought a useful response, such as 'private club' would be a better solution?

I agree it could hopefully be something different. I have asked about private member lists and if something other than an error could be returned.

Thanks Martin

Maybe but what brought the "403" response to mind was that when I was testing a non-API idea a couple of years ago, I found that private content in clubs returned a 403 status value instead of 404 which I'd been expecting.

For example, it's possible to download a page's HTML document using a conventional request but switch a club's forum from public to private and any page request suddenly gives 403, not 404.

I use those status codes to direct what my script does next, so I'd much prefer to receive "403" because it tells me to stop making those requests. All that 404 tells me on this site is that I probably need to make the same request later on.

Exactly. 404 means the end user did something wrong such as go to an invalid endpoint.

403 is more appropriate if you don't have permission to fetch the requested data. Chess.com isn't the only company that uses these error codes wrong, trust me 😅

Sure, but the clubs I request the API data for are clubs that I manage. There should be a way for admins to at least get this data from the API - OAuth token comes to mind.

I think we have to accept that if club content is tagged as private then that should mean something.

Worth remembering that a public API is available even to people who are not members of a site, all they need is the relevant endpoint(s). Although that might have changed since the site imposed a requirement to provide client ids with each request?

That might be possible, but would be separate from the Public API endpoint.

The contact info is a way to get in touch with a developer that may be causing issues with their code. It's not an authentication mechanism. Requiring it in code, is part of that. It's not needed for direct browser access

Thanks Martin, that clarifies something that I've wondered about for a while. It is the case then that someone who has never been near the site and doesn't have membership would still have full access to the site's available data via the API?

All that's needed is a set of endpoints.

That's why I mentioned it before.
At the moment I cannot see any good reasons to request an OAuth token. But if it would provide something like this, it could make it useful. 
These would valid and useful use cases: Accessing not public information that any user could get who are logged in. Or information that a specific user could get while logged in.

Here's a minor and pedantic point.

The Admins and co-ordinators are always visible on the club wrb page. Public data but not accessible via the endpoint if non-public members.

I don't think so? ...

https://api.chess.com/pub/club/oracles/members

{"code":0,"message":"An internal error has occurred. Please contact Chess.com Developer's Forum for further help https://www.chess.com/club/chess-com-developer-community ."}

https://api.chess.com/pub/club/oracles

  "admin": [
    "https://api.chess.com/pub/player/akszone",
    "https://api.chess.com/pub/player/niranjannavalgund",
    "https://api.chess.com/pub/player/you-win-sum",
    "https://api.chess.com/pub/player/mastermatthew52",
    "https://api.chess.com/pub/player/andrea",
    "https://api.chess.com/pub/player/varelse1",
    "https://api.chess.com/pub/player/gnafron1",
    "https://api.chess.com/pub/player/theman_withnoname"
  ],
  "visibility": "private",