INVALID_RESOURCE_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

The Application ID and API key pair does not match, or the key was revoked. Copy both fresh from the Algolia dashboard, making sure the ID and the key come from the same application, update the client, and requests authenticate. Never mix a key from one app with another app's ID.

The ID and the key are a pair. They must come from the same place.

Verbatim query

algolia API error: Invalid Application-ID or API key

Steps

1. Open the Algolia dashboard API keys page Select the application the integration is supposed to use. Expected: You are looking at the keys for the correct application.

2. Copy the Application ID and a valid API key from the same app Take both values together from the same screen. Use a key with the permissions the integration needs. Expected: An ID and key pair from one application.

3. Update the client configuration Replace both values wherever the generated client stores them, even if you think only one changed. Expected: The client sends the fresh pair on the next request.

4. Run a test search Send a simple search request to confirm authentication works. Expected: A 200 response with search results.

5. Label credentials per application in the generated client Store the app name alongside the ID and key so the next person cannot mix pairs across apps. Expected: Each credential set is tagged with its application.

Use this when

• Algolia rejects requests with "Invalid Application-ID or API Key."
• A generated client was configured by copying values from different dashboard screens.
• The same key works in one app's context and fails in another's.

Not for this skill when

• The error is a 403 about insufficient permissions, meaning the key is valid but lacks the right ACL.
• The problem is an index-not-found error.
• The failure is an Algolia rate limit.

Variant phrasings

"Invalid Application-ID or API Key" on indexing operations

Writes fail the same way as reads with a mismatched pair. Same fix.

403 invalid credentials wording on Algolia

Check whether it is truly a bad pair or a valid key with the wrong ACL; the fixes differ.

Why it happens

Algolia API keys are scoped to a single application, and the dashboard's app switcher makes it easy to copy an Application ID from one app and a key from another. Generated clients also tend to accumulate credentials across environments until nobody knows which pair belongs to which app. The API sees a mismatched pair and rejects it flatly.

Edge cases

• Admin keys, search-only keys, and restricted keys have different powers; a valid pair with the wrong key type still fails the operation.
• Keys copied with leading or trailing whitespace fail; trim on paste.
• The dashboard app switcher is the classic mixing point; always re-check which app is selected.
• Restricted keys with referer or IP limits fail from unexpected origins even though the pair is valid.
• Rotating a key in the dashboard instantly kills the old one; update every client that used it.

Provenance

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

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

Thread query: algolia API error: Invalid Application-ID or API key

TL;DR: The Application ID and API key pair does not match, or the key was revoked. Copy both fresh from the Algolia dashboard, making sure the ID and the key come from the same application, update the client, and requests authenticate. Never mix a key from one app with another app's ID.

Not specified by the original author.

TL;DR

The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.

Error

{
  "status": "error",
  "message": "Invalid input JSON on line 1, column 1: filterGroups is invalid",
  "correlationId": "aaaa-bbbb-cccc"
}

Steps

1. Check the top-level shape: filterGroups must be a list, even for one filter. Expected: a single filter still sits inside two lists.
2. Check each filter has propertyName (internal name), operator, and value. Expected: no missing keys.
3. Match the operator to the property type: EQ and NE for most, GT/LT for numbers and dates, CONTAINS_TOKEN for text search. Expected: type-appropriate operators only.
4. Match the value type: numbers as numbers, dates as millisecond timestamps, enumerations as internal option values. Expected: no quoted numbers or label strings.
5. Test the filter in isolation with one group and one filter before adding complexity. Expected: the minimal query returns 200, then you expand.

When to use

• POST to /crm/v3/objects/[object]/search returns 400 mentioning filterGroups.
• An agent's dedupe search worked for contacts but 400s for companies (different property types).
• After adding a second filter group the query breaks.

When not to use

• Search 429s (rate limits, different fix).
• "property does not exist" (wrong name, different fix).
• Empty results with a 200 (the filter is valid but matches nothing).

Tool compatibility

• HubSpot CRM API v3 search endpoints for contacts, companies, deals, tickets.
• Private apps with crm.objects.[object].read scopes.

Variant phrasings

Invalid input JSON: filterGroups

The nesting is wrong; wrap filters in groups, groups in the list.

operator not supported for property type

The operator does not fit the property; pick a type-appropriate one.

Why it happens

The search DSL looks like JSON but behaves like a typed query language. The API validates structure before semantics, so a shape mistake 400s before any searching happens.

Edge cases

• Filters across associations need the associations filter form, not a property filter on the parent.
• More than a few filter groups can hit undocumented complexity limits; split into multiple searches.
• Date filters want milliseconds since epoch; ISO strings 400 on some endpoints.

Provenance

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

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

Thread query: "hubspot search api 400 filterGroups invalid"

TL;DR: The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.