I’m trying to access the
application/settings api for a managed (gitlab.com) instance, but I’m getting a 403 Forbidden response no matter how I try it.
I tried using a Personal token, I tried using an Oauth token (both with all the scopes enabled), I even tried using the ui sessions cookie, but no matter what I try the response is still 403.
Does anybody know what I need to do in order to access the application settings via API?
Hi @alon. Welcome to the GitLab community forum!
403 forbidden with your API key would indicate that you’re not an administrator. You must be an administrator in order to perform
GET /application/settings. Without an Admin’s API token, the endpoint will return 403.
If you try this using the personal access token of a GitLab Administrator’s, you should be able to see the expected application settings output without a 403 error.
Thanks for the help!
I am using the account that created the project, and am giving the tokens I use every scope I can. How can I get administrator permissions on my gitlab.com (not self managed) project?
Thanks for clarifying that this is for GitLab.com, not a self-managed instance.
/application/settings endpoint gives details about the GitLab instance. For GitLab.com, this API endpoint and functionality is not available, by design.
GitLab Administrators are Admins at the instance level, and able to modify the application settings and options. This is the case for all API endpoints requiring admin privileges. There is no way to set an “Admin” of a single project as “Owner” is the highest level of permissions available as a project member.
I hope this answers your questions. If you feel the documentation on this could be improved upon, I encourage you to create an issue or submit a merge request to improve it.
Thank you for settling this issue.
In my opinion this distinction is missing from the documentation, especially as these apis are displayed even when ‘gitlab.com’ is chosen from the version dropdown menu. I also think this is quite a large downside to choosing your saas offering, since it greatly limits the possibilities of automated management.
That being said, considering it’s like this by design, I don’t think an issue or a merge request is the right step for me. hopefully you will reconsider this design choice in the future.
Thanks again for the help