Creating an API that returns true/false based on a hardcoded query doesn't seem such a good solution, because it isn't flexible at all and doesn't fit into REST, because it doesn't represent an action on a resource.

Sure it does - the resource is some named collection of information (aka "a document", although you can implement that any way you like behind the api facade), and the action on the resource is GET (please send me a copy of the current representation of the document).

As REST is designed to be efficient for large-grained hypermedia, you're more likely to want a design that returns a bunch of information all bundled together, rather than a document that describes a single bit, but that's something you get to decide for yourself.

How do I create an api that checks if a certain condition is met, while making it as flexible as possible and adhering to REST principles?

In that case, you're probably going to end up defining a family of resources, each of which has their own current representation (but under the covers might be implemented using a single "request handler" that knows how to choose the correct implementation from the target resource of the request).

So REST is going to tell you that you can do that (it's your own resource space) and that you'll probably want to use some readily standardizable form for describing the space of identifiers (ie: choosing identifiers that can be described using URI Templates).

As a general rule, you'll want to avoid using identifiers that couple you to tightly to a particular implementation of handler unless you are confident that the particular implementation is "permanent".

In terms of the spelling conventions you use to encode the variations of resources into your identifiers -- REST doesn't care what spelling conventions you use.