In your question does not reference whether your API is in RESTful or SOAP but how did you put a "REST" TAG calculation that is then RESTful. However what I'm going to mention makes sense to both.
OAUTH is actually for authorization as soon as it is delivered a TOKEN is supposed to access within the policy defined for the API. But you are authorized to use it. Therefore requests are only open to whom your system will deliver a TOKEN.
Regarding ENDPOINT's and taking into account that you will create a usage documentation for your API, it is exposed and there are several reasons ... but essentially because it is pure HTTP protocol and already now because it is the basis of the whole concept of an API.
When writing these lines comes the idea limitations that you can put, for example, in your server's firewall, to accept only a certain IP requets. Or even use SSL to exclude those who do not present signed certificates ... the universe of options is vast.
The creation of 'user / user (in my language)' specific to unauthorized requests contributed nothing to the security of your API.
Once again finding out about ENDPOINT is the least of your problems. You have already thought about those requests that will access a database and that by using or several attacks can block your service ... I think there is really a lot to think about.
In conclusion, a API is public and period. OAuth is clearly the way to authorize its use. For me, OAuth is pure delegation ... being authentication and access to resources another situation. In the latter case OAuth has a solution so I advise you to analyze what in OAuth is called by SCOPES or permissions that can help to solve some points of your implementation. See also openID , it might work for you.
