SonarQube WebAPI v2 - OpenAPI specification, various questions regarding information etc

(Self-Hosted SonarQube Developer Edition 9.9 LTA)

As our team is in the phase of automating a few things with SonarQube we started looking at the WebAPI v2. To our surprise there seems to be some crucial information that is not available in the API. Questions below:

  1. Where is the OpenAPI specification for the API?
  2. Where can the following information be accessed via the API?
    a. project token for a SonarQube project
    b. SCM repository url for a SonarQube project


This ticket mentioned that there is a OpenAPI specification on Next. Not sure how it relates to the current WebAPI v2. We are on 9.9, so it could be that it is available with 10.x unless it’s new for Next. What is Next - next minor or major version?

Hi Jimisola,

Have you tried this via the UI? The best way to master the API is to perform the desired action via the UI and eavesdrop to see which calls the UI made to accomplish the action.

You may also find this guide helpful.

Regarding an OpenAPI specification, I’m not sure one exists yet. The API was built purely to serve the UI, which is why eavesdropping on your browser to see what calls the UI makes is the best way to master the API.


Hi Ann,

Thank you for that information. I managed to find the project key by eavesdropping.
Sadly, I can’t seem to find the url to the git repo in SonarQube other than for pull requests.
Can this really be?

I never actually realized that there isn’t a “click here to get to git repository” is the SonarQube UI.

So, I don’t have a fail-safe way to get the git repo url. Currently, we can try get git repo url from:

  1. pull requests
  2. external links

But, none of those have to exist. I looked at (10.6) but didn’t find any info there either.

However, SonarCloud UI links to the latest commit in SCM. Latest commit is taken from api/project_branches/list. Sadly, this is just the commit sha and does not include a link to to git repo, so the link in SonarCloud UI gets the info about the git repo url from somewhere else.

The commit sha would have been enough since I would be able to get the GitLab Project using that.

How do I file a feature request?


Once you tell us why you need the data, we can consider this your feature request and I’ll forward it to the Project Managers.


We need the data because it’s a way (only?) to link a SonarQube project with a SCM project (here: GitLab) unless you use the SonarQube project key. We want to automate our CI/CD even more and set project key and project token automatically in the pipeline. Hence, remove the need for setting all together. Too much configuration of tools. SonarLint handles it nicely.

SonarLint does not use but it manages to bind nonetheless, I just haven’t been able to figure out how (I end up here and then it seems like it off to the LSP (“sonarlint/suggestBinding”). If SonarLint’s way of doing it is reliable and easy to implement then we might use that solution as well. Do you happen do have more details on this?

We will run a job in our pipeline before sonar:sonar/sonar scanner that will either create or set environment variables to be used subsequently.

I found a semi workaround. I can look for common files such as pom.xml, pyproject.toml and then use endpoint api/sources/lines to get a commit sha. I can then search for that commit sha in GitLab repo url and retrieve the project’s GitLab repo url.

UPDATE: I found some information about SonarLint’s auto suggestion here now. We did have in the git repo but removed it just to confirm. So, the question remains if the suggestions are from an API call to SonarQube or if the logic is in SonarLint.


Thanks for this detail. But I still don’t understand why you want to know the repo from the SonarQube side. Everything you’ve talked about here is from the CI side / project side where you presumably already know the repo…?


Ok. I’ll try again. Maybe I missed an easier solution.

How would you match a GitLab project (without any SonarQube information) to a SonarQube project using the SonarQube API?

Keep in mind that the pipeline runs for a GitLab repository and now needs to figure out which SonarQube project it matches so that it can get the project key and project token for sonar scanner and badges.

None of the GitLab project information seems to be stored in SonarQube (i.e. GitLab project id, slug/path or repo url).

If the SCM repo url is available in SonarQube via the API then it should be quite easy to match with the correct GitLab project.


Well, I would look in the project itself:

  • the Maven or Gradle build files, which should hold project ID
  • the pipeline script which may add the ID on the command line, e.g. for .NET projects

See… this part I really don’t understand. I feel like you’re making it really hard on yourself by not just creating the file once and checking it into the project. Especially since you mention looking up not just the project ID, but also the token. Token values aren’t retrievable from SonarQube; they’re shown once, at creation and not again.

Can you share why you’re working so hard not to just save this data in the project?


Hi Ann,

Yes, one can look in Maven or Gradle files, package.json, pyproject.toml, Dockerfile etc.
We don’t want such a solution but one that works with a git repository irrespective of it’s content.
We are trying to get ride of the all in all. We want a configuration less solution.

The token information seems to be available via the API.

Yes, our use case started with challenge of creating of using SonarQube’s badges for GitLab Badges. We don’t want to add them manually and you can’t create them on a Group level (see Sonar Badges in GitLab - #4 by lfvjimisola and Add new placeholders for group/project badges (#22278) · Issues · / GitLab · GitLab) due to lack of linking options between SonarQube and GitLab.

I then came up with a solution to add badges on a group level with project id as a place holder. The url will go to our in redirect service that would download to fetch sonarqube key and token. The redirect service would then redirect to the requested SonarQube badges type url.

Then we thought we might get ride of all together and minimize the configuration needed to setup new projects. Once the initial linking is done there would be a need for with my solution. But that requires that we can connect a GitLab project with a SonarQube project - just like SonarLint does. Hence, my question if the git repo url is stored or any other information that could be used for figuring out what SonarQube project a particular GitLab projects it connected to.


Hi Jimisola,

Thanks for sharing.

You can choose to pass the sonar.links.scm parameter. If you supply it, I believe it’s displayed on the Project Information tab, so you can use your browser’s Developer Tools to spy on the call the UI makes to know how to retrieve the information.


1 Like

A good thing with this wish of automation is that I’ve been digging around GitLab quite a lot.

I’m guessing that the DevOps Platform Integration is made when I create a SonarQube project from within SonarQube via “Create Project → From GitLab”.

Is there a way to make maven sonar plugin pass this information after the fact for our projects that we’re created this way?

@ganncamp I found what I believe is a bug in one of the endpoints.


will return the GitLab project’s original values for

  • “sqProjectKey”: “sysdev_lisp3_tests_int001_code_AXwmuUqhccjl3LgiYrr0”,
  • “sqProjectName”: “x.lips3.test.integrations.int001”

instead of the current ones (see e.g. components/show):

“component”: {
“key”: “sysdev_lisp3_tests_ms001_code_AXwmuUqhccjl3LgiYrr0”

The two keys are two different components, but the api/alm_integrations/search_gitlab_repos is listing the old (incorrect one).

EDIT: I did a little bit more troubleshooting. There were in fact two components that had the same gitlab project id and the older one was the one showing up in search_gitlab_repos.
I consider this a bug. The API should show the information for the current gitlab projects.


We try to keep it to one topic per thread. Otherwise, it can get messy, fast.

Could you create new topics for the new issues, please?


Sure. I created a new topic: Bug report: Web API endpoint search_gitlab_repos lists old component data instead of new