As title implies - If a chart is tracked, but there are no scores on the chart, then there will be no server record. The spec doesn't disclose what to return here. I think null is sensible, or maybe some sort of error code.

Open for comments.

The USCIR specification currently does not support a status code for a deferred import, which TachiIR will be using.

The 22 status code should imply that the score import has been accepted, but that the score will not display for the user yet.

The implementation reason for this in TachiIR is such that a chart has to be played by N unique users before it is counted as a "real" chart, to avoid IR spam.

If the request has, say, N of 10, but the server only has 5 unique PBs, the specification does not specify what to do explicitly. As it stands, I think the reasonable thing to do is to assume that N is the upper bound for the returned documents, but may be less (incl. 0) for any reason.

This is probably intentional, but this returns either 42 or 20, instead of the 42 | 44 | 20 that the other chart endpoints do.

For consistencies sake, the handling of chart-exists/chart-not-found could be moved to the client.

minor gripe and doesn't really matter.

Should probably be documented that POST /scores can return 40 if the score document/chart document provided is invalid. This probably wont happen, but has to be accounted for anyway.

Maybe I'm reading this wrong but it isn't clear how options.autoFlags works with gameFlags. Don't they represent the same thing?

Or rather, isn't options in general just a more sensible form of gameFlags, and we can omit it entirely?

This endpoint mandates mode and n params, but it is unspecified what to do if they are invalid.

I think returning 200 with 40 in the body is the reasonable approach.

Specifications should probably also be allowed to return 40 for unsupported args - such as an n param too great, or mode of rivals if it is unsupported. etc.