API

The Quevell API is the same set of methods the product's own interface uses, opened up for integrations. It speaks JSON both ways and acts only as a service account: people do not get personal tokens. This page covers how to call it and what it returns, and ends with the methods you may call.

Address#

https://<key>.quevell.com/api

<key> is your company's key, the one in the product's address bar. Call your own company's address. A token belongs to one company, and at another company's address the request is rejected with auth.tenant_mismatch (403). There is no version number in the path.

Signing in#

Every request carries a service account token:

Authorization: Bearer qvl_...

Service accounts explains how to mint a token, how to narrow its rights, and how to get a short-lived token through an OAuth client. A request with no token, or with one that is unknown, expired or revoked, gets 401 auth.required. A token that lacks the right for an action gets 403 authorization.forbidden.

Responses and errors#

A successful response is the object, list or page itself, with no wrapper around it. An error always arrives in the same envelope:

{
  "code": "concurrency.version_conflict",
  "message": "Issue was modified concurrently",
  "status": 409,
  "path": "/api/issues/6f1c.../transitions/...",
  "correlationId": "9b2e...",
  "timestamp": "2026-09-17T08:00:00Z",
  "details": {}
}

• code is stable. Branch on it.
• message is a sentence for a person, in English. It may be reworded any day, so never branch on message.
• details holds specifics when there are any: field errors in details.fieldErrors, how long to wait in details.retryAfterSeconds.
• correlationId identifies the request. Every response also carries it in the X-Correlation-Id header; quote it when you contact support.

The most common codes:

Modules add codes in their own namespaces, such as note.*, sprint.* and identity.*. Handle an unfamiliar code by its status.

Dates and times#

Moments are sent and accepted in UTC, as ISO-8601 strings ending in Z. Calendar days, such as an issue's due date or the day of a worklog, travel as year-month-day with no time. Neither the server's time zone nor the person's affects a response; converting to local time is up to your program.

Pages and cursors#

Long lists come in pages. A page has items and nextCursor, and some methods add total. To get the next page, repeat the request with cursor=<nextCursor>; an empty nextCursor means you have them all. limit sets the page size, and each method's maximum is in the reference. There are no page numbers or offsets.

A cursor is tied to the sort order it was issued under. Used with a different order, it is rejected.

Search and QQL#

GET /api/issues/search searches every project visible to you. text takes either plain words or a QQL query:

curl -G https://<key>.quevell.com/api/issues/search \
  -H "Authorization: Bearer qvl_..." \
  --data-urlencode 'text=project = OFFICE and status != Done order by updated desc' \
  --data-urlencode 'mode=QUERY'

Without mode, the server guesses whether text is words or a query and reports its guess in the response's mode. An integration should set mode=QUERY outright. Order comes from ORDER BY inside the query, most recently updated first by default. filterId runs a saved filter.

Issues the token may not see are left out entirely: they appear in neither items nor total.

Versions and conflicts#

Objects that change carry a version. When you change one, send the version you read as expectedVersion. If somebody changed the object first, you get 409 concurrency.version_conflict, or a module's code ending in version_conflict. Read the object again and decide whether your change still applies.

Sending the same change to an issue twice does nothing the second time and writes no new event. Creating is different: a repeated POST creates a second object. If a create request was cut off, check whether the object exists before you send it again.

Limits#

How the counting works:

• A minute is a calendar minute in UTC, not a sliding window. Every request with a working token counts, including one rejected for lack of rights.
• A day is a calendar day in UTC. A record is every event the account leaves in the audit trail: creating or changing an issue, a comment, a worklog, and also downloading an attachment or exporting CSV. Reading that leaves no event uses no records.
• All of an account's tokens, minted by hand or handed out by an OAuth client, share one allowance.

Every 429 says how long to wait, in the Retry-After header and as the same number in details.retryAfterSeconds. For the per-minute limits that is the seconds left in the minute; for the daily ones, the time until midnight UTC.

HTTP/1.1 429 Too Many Requests
Retry-After: 17

{"code":"tenant.rate_limited","status":429,"details":{"retryAfterSeconds":17},...}

Wait that long, then retry. Retrying sooner is pointless, because those requests count too. A 409 files.storage_quota_exceeded carries usedBytes and limitBytes in details.

Examples#

Create an issue:

curl -X POST https://<key>.quevell.com/api/projects/<projectId>/issues \
  -H "Authorization: Bearer qvl_..." \
  -H "Content-Type: application/json" \
  -d '{"summary": "Replace the toner", "description": "The printer on the third floor"}'

Move an issue to another status: first ask which transitions are available, then perform the one you want, passing the issue's version.

curl https://<key>.quevell.com/api/issues/<issueId>/transitions \
  -H "Authorization: Bearer qvl_..."

curl -X POST https://<key>.quevell.com/api/issues/<issueId>/transitions/<transitionId> \
  -H "Authorization: Bearer qvl_..." \
  -H "Content-Type: application/json" \
  -d '{"expectedVersion": 3}'

Add a comment:

curl -X POST https://<key>.quevell.com/api/issues/<issueId>/comments \
  -H "Authorization: Bearer qvl_..." \
  -H "Content-Type: application/json" \
  -d '{"body": "Toner replaced"}'

Method reference#

This list is read from the product's code and checked against it on every build, so it never names a method that is gone. Sign-in, company administration and the helpers behind individual screens are left out, because their shape changes with the interface. A right named in a description is required of both the account's role and the token; seeing the project is required everywhere and is not repeated.