Web API
SonarQube provides a web API to access its functionalities from applications.
The web services composing the web API are documented within SonarQube. To access the documentation, select the help button from the top bar in SonarQube:
![](https://assets-eu-01.kc-usercontent.com:443/5e986e54-339c-01a9-7c7c-26cbc5a344d5/ef417efc-316c-4516-8ba5-a18e93680762/web-api-v2.png?w=321&h=473&auto=format&fit=crop)
Note that the Web API V2 will gradually replace the Web API as endpoints get deprecated and replaced.
Authenticating to the Web API
Administrative web services are secured and require the user to have specific permissions.
To authenticate to the Web API, we recommend that you use the user token method. To do so, use the bearer authentication scheme as follows:
curl --header 'Authorization: Bearer MY_TOKEN' https://sonarqube.com/api/user_tokens/search
For detailed information on user tokens and authentication, see Generating and using tokens.
Sending an API request
To make a request, you need to find the HTTP method and the right path for the operation that you want to use.
It’s highly recommended to use form data parameters when making POST requests to the Web API. If you use URI query parameters instead then these parameters won’t be securely passed to the endpoint.
Sample API request
If, for example, you want to use the Web API to extract measures, you can make a “GET MEASURES” call to the /api/measures
endpoint in order to extract measures of a given metric for a given project. For this example, a possible request and response are shown below.
Request
curl --request GET \
--url 'https://sonarqube.com/api/measures/component?metricKeys=ncloc%2Ccode_smells%2Ccomplexity&component=my_project_key' \
--header 'Authorization: Bearer my_token'
Response
{
"component": {
"id": "id",
"key": "my_project_key",
"name": "my_project_name",
"qualifier": "TRK",
"measures": [
{
"metric": "complexity",
"value": "4214"
},
{
"metric": "code_smells",
"value": "8595",
"bestValue": false
},
{
"metric": "ncloc",
"value": "51667"
}
]
}
}
Web API deprecation policy
The goal of the deprecation policy is to make sure that users are aware of what is changing and have time to adjust before a component of the API is dropped at a given planned date.
The Web API deprecation policy states that:
- An API component must be deprecated before being dropped. Furthermore, if the underlying feature is not being dropped, a replacement component must immediately be provided.
- A deprecated API component must be fully supported until its drop (For instance the implementation of a deprecated method can't be replaced by throwing a new UnsupportedOperationException()).
- The API release cycle is tied to the SonarQube release cycle.
- If an API component is deprecated in version X.Y, this component is planned to be dropped in version (X+1).0. For example, a component deprecated in the 10.x version is kept until the 10.x LTA (Long Term Active) version: it will be dropped in the 11.0 version.
Under special circumstances, for example, when there are security vulnerabilities that need to be addressed, we might make an exception and drop the deprecated API component earlier.
This leads to the following policy recommendations for API users:
- Regularly monitor the deprecation of API components and check if you’re currently using them. See Monitoring the deprecated API components.
- If you're currently using deprecated API components:
- Don't add new uses of it.
- Make the necessary updates in your next few releases so you’re ready for any breaking changes after the next LTA release.
Was this page helpful?