If you are asking because someone on the internet told you your API is not really REST, you can safely stop worrying. If you are asking because you want to know whether your API is any good, that is a better question with a different answer.
The honest test is not “does this satisfy the six REST constraints.” It is: are your resources named consistently, do your HTTP methods mean what they mean everywhere else, do your status codes tell the truth, are your errors structured the same way across every endpoint, and can a developer who has used one of your APIs predict how the next one works? That is what people actually mean when they say an API feels RESTful, and it is what produces the outcome everyone wants.
The REST purity debates were the least productive argument in the history of this field. They pushed a lot of well-meaning people out of the shared conventions entirely, which is precisely the opposite of what the purists wanted. Consistency comes from inclusion, not from gatekeeping.
So: govern toward consistency, adopt the pragmatic conventions, skip the dogma, and accept that REST is a mess — just like everything else humans build at scale.