The only way we currently offer to check for the presence of a content in the archive is the /content endpoint.

For use cases such as being a backend for source code scanners it would be nice to have a batch version of the same endpoint; it would be more efficient and consume less rate limit "credits", with limited impact on our side. If needed, it would be OK for such endpoint to return less information about each individual content than what the current /content endpoint does (the bare minimum we need is a list of booleans stating whether the content is in the archive or not).

For the batch part, we can accept a POST request body with the list of content identifiers to check, as opposed to the current single id we accept via GET. That might justify overloading the current /content method (dispatching on GET v. POST) depending on how similar the return values will be in the two cases.