Introduction to the Qase API

Welcome to the Qase.io API! You can use our API to access Qase.io API endpoints, which allows to retrieve information about entities stored in database and perform actions with them. The API is organized around REST.

You can try using the API on the page API Reference or by getting to know the public page in Postman.

Authentication

Qase.io uses API tokens to authenticate requests. You can view and manage your API keys in API tokens pages.

Your API keys has the same access rights as your role in the app, so be sure to keep them secure! Do not share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.

Qase API expects for the API key to be included in all API requests to the server in a header that looks like the following:

Token: API_TOKEN

All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

API Rate limits

Rate limits apply per workspace. Every API token in a workspace shares the same limit, whether the requests are made using a personal access token or an app token, so issuing another token does not give you more throughput.

Two limits apply at the same time, and a request is served only when both of them allow it:

• A sustained limit, measured over the last 60 seconds. This is the plan limit.
• A burst limit, measured over a 10 second window, which stops the whole minute's allowance being spent at once.

The burst allowance refills continuously at the sustained rate, so over a full 10 seconds you can send the burst allowance plus what refills during it — 200 requests on a 600 per minute plan, for example. A workspace that stays under its per-minute limit can still be throttled if it sends those requests in a narrow spike.

Every response tells you where you stand:

• RateLimit-Policy — the limits in force, where q is the quota and w is the window in seconds.
• RateLimit — how much of each limit is left, where r is the requests remaining and t is the seconds until that limit frees a slot.
• X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset — a single-number mirror of the above, for older clients. They report whichever of the two limits is closer to being reached, and X-RateLimit-Reset is the Unix timestamp at which that window resets.

For example, on a workspace whose plan limit is 600 requests per minute:

RateLimit-Policy: "rpm";q=600;w=60, "burst";q=100;w=10
RateLimit: "rpm";r=412;t=37, "burst";r=88;t=2
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 88
X-RateLimit-Reset: 1756742400

Here the X-RateLimit-* headers describe the burst limit rather than the plan limit, because a spike is in progress and the burst limit is the one closer to being reached. These headers are the authoritative numbers for your workspace: if your limits have been adjusted for you, they will differ from the table above.

Once either limit is exceeded, clients receive an HTTP 429 with a Retry-After header telling them how many seconds to wait before sending requests again. The wait is calculated for each rejected request, so it is usually only a second or two rather than a full window:

Retry-After: 12

{
  "status": false,
  "errorMessage": "API rate limit exceeded."
}

In addition, a separate per-IP limit applies as a safety net for all traffic from one address. It sits well above the per-workspace limits, so under normal conditions you will reach your workspace limit first.

Access rights

Qase.io is using Role-based Access Control system to restrict some features usage in Web interface and the same rules are applied to API methods. In description for each method you will find a rule name, that is required to perform an action through API. If you don't have enough access rights, you will receive an error with 403 status code.

Error Codes