meilisearch error: invalid_api_key on search with a rotated key

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: Generate a new API key in Ashby, update the credential the agent reads, and backfill the sync window that failed. Then add a startup auth check and 401 alerting so the next rotation fails loudly instead of silently.

Ashby 401 "invalid API key"

1. In Ashby's admin settings, generate a new API key, coordinating timing since rotation invalidates the old key. Expected: a new key is issued.
2. Update the credential where the agent reads it and restart or reload the agent. Expected: the next API call returns 200.
3. Re-run the failed sync window to backfill records missed while auth was broken, checking for existing records first to avoid duplicates. Expected: missed records sync and counts reconcile.
4. Add monitoring: the agent validates auth on startup, alerts on repeated 401s, and logs the last successful sync time. Expected: silent failures become paged alerts.

Use this when

• Ashby returns 401 after a key rotation.
• The sync stopped with no alert.
• 401s correlate with an admin or security change.

Not for this skill when

• The error is 422 (validation, not auth).
• The error is 403 (permissions).
• The error is 429 (rate limiting).

Variant phrasings

• "Ashby API key rotated"
• "Ashby sync failing 401"
• "Ashby invalid API key sync"
• "Ashby authentication failed"

Why it happens

Rotating the key invalidates the old one immediately, and the agent kept presenting the stale credential. With no auth health check, every call failed and the sync died quietly while dashboards showed stale-but-present data.

Edge cases

• Ashby API keys are tied to an admin user; deactivating that admin kills the key too.
• Backfill carefully: check for existing records before re-creating to avoid duplicates.
• Run the backfill as a dry run first when the missed window is large.

Provenance

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

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

Thread query: Ashby 401 "invalid API key" after the key rotated and the agent's sync kept failing silently

TL;DR:

Not specified by the original author.

TL;DR

Rotate in overlap: create the new API key while the old one still works, roll agents to the new key in batches, verify data flow per batch, then revoke the old key. Never revoke first. The Datadog API key is org-wide, so a bad rotation blinds all monitoring at once; batch the rollout and watch the agent status dashboard throughout.

The query

Datadog agent "API key invalid": how to rotate safely

Use this when

• Agents report invalid API key errors
• Keys may be compromised
• Scheduled credential rotation
• Migrating key management

Not for when

• Datadog application keys (API access, different)
• Agent installation issues
• Check configuration errors

Steps

Step 1: Confirm the key is actually invalid

Check the agent's status output for the auth error and verify the key in the Datadog org settings. Keys get disabled on org changes or security events; confirm before rotating. Expected output: the key confirmed invalid or disabled, not a different auth issue.

Step 2: Create the new key alongside the old

Generate the new API key without deleting the old one. Both keys work during the transition; nothing breaks yet. Note which key is which. Expected output: a new valid key ready, old key still active.

Step 3: Roll agents in batches

Update agents to the new key in batches: config management, DaemonSet env, or however agents are deployed. Verify each batch reports data before moving to the next. Expected output: all agents on the new key, data flowing, verified per batch.

Step 4: Watch for stragglers on the old key

Monitor which hosts still authenticate with the old key (Datadog shows key usage). Stragglers are forgotten agents: snowflake hosts, old AMIs, decommissioned-but-running instances. Expected output: zero hosts on the old key, or the stragglers named and handled.

Step 5: Revoke the old key and document

Delete the old key and record the rotation. If the rotation was due to compromise, also review what the old key could have accessed during the exposure window. Expected output: old key revoked; rotation logged.

Provenance

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

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

Thread query: Datadog agent "API key invalid": how to rotate safely

TL;DR: Rotate in overlap: create the new API key while the old one still works, roll agents to the new key in batches, verify data flow per batch, then revoke the old key. Never revoke first. The Datadog API key is org-wide, so a bad rotation blinds all monitoring at once; batch the rollout and watch the agent status dashboard throughout.