QRebel provides a public API, allowing users to receive raw data for analysis and storage. The API is particularly useful when used from your CI server where automated tests are run. This setup allows you to inject QRebel performance regression detection into your existing CI/CD pipeline, so as to empower your test jobs with automated performance quality gates.

REST API authentication

Every QRebel project has a unique API token for authentication. This token is required for all API calls.

To acquire the project’s API token, an administrator needs to enable API functionality for the project from the Settings section. Once an API token has been generated for a project, you can choose to regenerate the token or disable API for the project.


The token is passed using the standard Authorization HTTP header.

Authorization: {API token}



API queries support only user-defined build names.

Here is an example of a complete API query:


The elements used in this query include:

  •{appName}/issues/ – QRebel URL with the application title.

  • targetBuild={build} – target build for the query (required).

  • targetVersion={version} – target version for the query (optional).

  • baselineBuild={build} – baseline build for the comparison. When none is specified, the comparison of targetBuild is performed against the globally set static threshold.

  • baselineVersion={version} – baseline version for the comparison. (NB! baselineVersion cannot be specified without baselineBuild).

  • defaultBaseline – can be used when no baselineBuild is specified, see the next section.

  • issues=DURATION,IO,EXCEPTIONS – types of issues for the query. When none specified, all issue types are returned by default.

  • DURATION – returns slow request issues.

  • IO – returns excessive IO issues.

  • EXCEPTIONS – returns exception type issues.

Default baseline

You can define the default baseline build (with optional version) to be used for comparison. To set a default baseline, use the following API call:

JSON Payload:
{ "build": "build1" }
{ "build": "build1", "version": "1.0" }

A good candidate for the default baseline is the last build deployed to production.

To compare to the default baseline, use the defaultBaseline query parameter:


Query examples

Complete query example:


Build versus static threshold with all issue types (two equivalents):


Exceptions only:


Compare against the default baseline build:


Query response example

This is an example of the REST API query JSON response (quotes omitted for brevity).

    appName: string,
    targetBuild: string,
    targetVersion: string
    baselineBuild: string,
    baselineVersion: string
    issuesCount: {
        duration: number,
        io: number,
        exceptions: number
    entryPoints: [
            hits: number,
            name: string,
            duration: {
                slowestPercentile: number,
                averageIncrease: decimal,
                scopePercentage: number
            io: {
                highestPercentile: number,
                averageIncrease: decimal,
                scopePercentage: number
            exceptions: [
                exception: {
                    name: string,
                    count: number
    appViewUrl: string