EaserixDocs
DevelopersAPI referenceTasksIssues

Which of the caller's workspaces an issue key opens in, for an old link

For an old link that names an issue by key (`/tasks/issue/ENG-12`), so the app can send the tab to `/tasks/w/<slug>/issue/<id>`. A key is unique only within one workspace, so it can match in several of the caller's workspaces: every match is listed (sorted by slug), and the app offers a choice when there is more than one. It looks only in workspaces the caller is a member of, at most 25. A match is listed only when Tasks would let the caller open the issue in its own workspace, by the same rules as `locateIssue`. When nothing matches the answer is the same 404 as every other miss, never an empty list: a malformed key, a request made with an API key or an OAuth grant. Both answers are `Cache-Control: no-store`. Rate-limited per user and per client IP, together with `locateIssue`.

View as Markdown
GET
/v1/issues/locate
AuthorizationBearer <token>

In: header

Query Parameters

key*string

The issue key as written, for example ENG-12 (any case).

Response Body

application/json

application/json

application/json

curl -X GET "https://example.com/v1/issues/locate?key=string"
{  "matches": [    {      "workspace_id": "0967198e-ec7b-4c6b-b4d3-f71244cadbe9",      "slug": "string",      "issue_id": "117c70c4-891b-49ba-96f2-b7599e2af0f7"    }  ]}

Grouped issue counts

Totals for the issues the caller can see, grouped, honouring every filter listIssues honours because it shares the same query builder. A count walking a different predicate than the list beside it would put two numbers on screen that disagree, with neither looking wrong alone. Exists because a paged list cannot answer "how many". Group headers, board columns and the progress bars on the cycles and projects pages each need a real total per group, and one grouped query serves a whole screen where per-group requests would take one per column. Each group carries `total` and `done` - both, because a progress bar needs two numbers and fetching them separately would double the requests per bar. `done` counts issues whose state is of the `completed` type. `key` is always a string, including for priority, which groups on an integer column. A null key is a real group: unassigned, no project, or no cycle. Groups holding no issues are ABSENT rather than zero - the caller knows its own states, projects and cycles and can render those as zero, which the server cannot do for assignees.

Which workspace an issue is in, for a link that names no workspace

For an old link (`/tasks/issue/<id>`, an email from before workspace URLs), so the app can send the tab to `/tasks/w/<slug>/issue/<id>`. It works across the caller's workspaces: the token may be for any of them. It answers only when Tasks would let the caller open the issue in its own workspace: they are a member with a product seat, Tasks is on there, and they can read the issue's team (they are on it, or they hold data.read_all there, or it is their personal workspace). Deleted issues are not located. Every other case gets the same 404, byte for byte: no such issue, someone else's issue, a team the caller isn't on, Tasks turned off there, a malformed id, or a request made with an API key or an OAuth grant (those are bound to one workspace by consent). Both answers are `Cache-Control: no-store`. Rate-limited per user and per client IP (the edge's CF-Connecting-IP).