Clarify API documentation on GitLab.com vs. self-managed

Problem

Our API documentation currently describes endpoints without describing whether or not they're available for users using GitLab.com. Using the Users API docs as an example, there's no indication that there's a difference between self-managed and GitLab.com API access. However, since admin API access on GitLab.com is restricted to a small subset of GitLab, Inc. employees, a customer on GitLab.com won't be able to use any of these admin endpoints.

One notable customer on GitLab.com described this as really frustrating: "It's very annoying to go through the docs, see the exact thing I need, and then realize that I don't get to use it since I'm not an admin".

Proposal

I don't have an ironclad proposal, but reorganizing our API documents might help. Instead of organizing our docs by call, like:

• List users
  • For normal users
  • For admins

Consider structuring these as such:

• For normal users
  • List users
• For admins (self-managed only)
  • List users

In the "for admins" section, list out all endpoints that require admin access and note that these calls are specific to self-managed instances for now.