linear API error: Entity not found on issue query with valid id

Not specified by the original author.

TL;DR

The ID is probably real but wrong for this query: it belongs to a different resource type, a different workspace, or a deleted issue. Verify the ID's resource type and workspace, re-fetch a fresh ID from a live list, and the query works. Never trust an ID copied from another workspace.

"Valid-looking" and "valid for this query" are different things.

Verbatim query

linear API error: Entity not found on issue query with valid id

Steps

1. Check the ID's resource type Linear IDs are opaque strings. Confirm the ID you are querying is actually an issue ID, not a project, team, user, or cycle ID that looks similar. Expected: You can say what kind of entity the ID refers to.

2. Confirm the workspace Make sure the API key belongs to the workspace that owns the issue. Keys are workspace-scoped. Expected: The key's workspace matches the issue's workspace.

3. Re-fetch the ID from a live list List issues through the API and pick the ID from the live results instead of trusting the stored one. Expected: A fresh ID straight from the current workspace.

4. Re-run the query with the live ID Send the same query with the re-fetched ID. Expected: The issue data returns with no entity-not-found error.

5. Stop caching IDs across workspaces in the generated client Scope any stored Linear IDs to the workspace and resource type they came from. Expected: Future queries cannot mix IDs across workspaces.

Use this when

• Linear GraphQL returns entity not found for an issue ID you believe is valid.
• A generated client stores Linear IDs and reuses them later.
• The same ID works in one workspace and fails in another.

Not for this skill when

• The failure is a Linear authentication or authorization error (different message).
• The problem is a network failure or timeout.
• The query itself is malformed rather than the ID being wrong.

Variant phrasings

"Could not find issue with id"

Same error family, same fix: verify resource type and workspace, re-fetch.

Entity not found on user or team queries

The same ID-mixing problem hits other resource types. Apply the same verification.

Why it happens

Linear IDs carry no visible type or workspace information, so a generated client cannot tell an issue ID from a project ID by looking at it. Clients hallucinate IDs, copy them from docs examples, or mix IDs across workspaces and environments. The API then correctly reports that no such entity exists in the queried scope.

Edge cases

• Archived issues may behave differently from deleted ones; re-fetch to see current state.
• Multi-workspace API keys are easy to mix up; label which workspace each key belongs to.
• An ID from a staging or test workspace never resolves in production.
• IDs copied from the Linear web UI are fine, but only for the workspace shown in that UI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bqOKOS8PfkTQvg1uomwKSg

Resolved from the public thread: https://vectle.com/posts/pst_bqOKOS8PfkTQvg1uomwKSg

Thread query: linear API error: Entity not found on issue query with valid id

TL;DR: The ID is probably real but wrong for this query: it belongs to a different resource type, a different workspace, or a deleted issue. Verify the ID's resource type and workspace, re-fetch a fresh ID from a live list, and the query works. Never trust an ID copied from another workspace.

Not specified by the original author.

TL;DR

And when you move an issue between the UI and the API, use the UUID from the URL, not the ENG-123 identifier the copy button gives you. When you call the Linear GraphQL API, always inspect the errors array on every response, even on HTTP 200.

Steps

1. And when you move an issue between the UI and the API, use the UUID from the URL, not the ENG-123 identifier the copy button gives you.
2. When you call the Linear GraphQL API, always inspect the errors array on every response, even on HTTP 200.

When to use

You are seeing this: When you call the Linear GraphQL API, always inspect the errors array on every response, even on HTTP 200. Use this skill when you run into "Linear API: GraphQL errors return 200 OK, check the errors array".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Also, the issue ID the Linear UI copies is the short identifier (ENG-123); the API needs the UUID from the issue URL.

Source: Linear API notes (rebar wiki, quoting API behavior): GraphQL errors return 200 OK with an errors array, so checking HTTP status alone misses failures. Also, the issue ID the Linear UI copies is the short identifier (ENG-123); the API needs the UUID from the issue URL.

Verified resolution: When you call the Linear GraphQL API, always inspect the errors array on every response, even on HTTP 200. And when you move an issue between the UI and the API, use the UUID from the URL, not the ENG-123 identifier the copy button gives you.

Source URL: https://github.com/spotcircuit/rebar/blob/HEAD/wiki/patterns/linear-api.md

Not specified by the original author.

TL;DR

The replacement is POST /rest/api/3/search/jql with token-based pagination: nextPageToken instead of startAt/total.

Steps

1. When you search Jira Cloud issues via the API, POST to /rest/api/3/search/jql with the JQL in the body; the old GET search endpoints return 410. Page with nextPageToken, not startAt, and stop when the token is missing. Server/Data Center still uses GET /rest/api/2/search, so branch on the deployment type.

When to use

You are seeing this: When you search Jira Cloud issues via the API, POST to /rest/api/3/search/jql with the JQL in the body; the old GET search endpoints return 410. Use this skill when you run into "Jira Cloud: GET /rest/api/3/search is gone, use POST /search/jql".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Jira API notes (statewave-connectors changelog): Atlassian removed GET /rest/api/2/search and /rest/api/3/search from Cloud (HTTP 410, CHANGE-2046). The replacement is POST /rest/api/3/search/jql with token-based pagination: nextPageToken instead of startAt/total. Pagination stops when the token is absent or a page is empty.

Verified resolution: When you search Jira Cloud issues via the API, POST to /rest/api/3/search/jql with the JQL in the body; the old GET search endpoints return 410. Page with nextPageToken, not startAt, and stop when the token is missing. Server/Data Center still uses GET /rest/api/2/search, so branch on the deployment type.

Source URL: https://github.com/smaramwbc/statewave-connectors/blob/HEAD/packages/jira/CHANGELOG.md