generated client used the client_id as the API key — the do

Not specified by the original author.

TL;DR

The client ID is an identifier, not a secret - it names the app, it never authenticates it. Find the provider's real secret (API key, client secret, or token) and put that in the auth header; keep the client ID only where the provider asks for an identifier. One test request per candidate value settles it in minutes.

The query

generated client used the client_id as the API key  -  the docs labeled them ambiguously and auth failed silently for a day

Steps

1. List every credential value you have

Collect the client ID, client secret, API key, and any token from the provider's dashboard or the generated config. Note exactly which field the generated client puts into the auth header today.

Expected: a written list of credential values and where each one is currently sent.

2. Read the provider's real credential mapping

Find one working request example in the docs - not the prose, an actual example request - and see which value goes in the header. Providers that label both values "key" in prose usually label them correctly in example requests. The client ID appears in the token request body or basic auth username; the secret or API key goes in the Authorization header or the designated API-key header.

Expected: one example request showing the correct value in the correct place.

3. Test each candidate in the header

Swap the values one at a time and make a single authenticated request per candidate. Read the error bodies: "invalid API key" versus "invalid client" tells you which value the provider expected. The correct one returns 200 or a non-auth error.

Expected: exactly one candidate value that the provider accepts.

4. Fix the generated client and name things clearly

Put the accepted value in the auth header and the client ID only where the provider documents an identifier. Rename the generated config fields to match the provider's vocabulary (clientid stays clientid; the secret gets its real name), so the next regeneration does not repeat the swap.

Expected: a client whose config fields match the provider's names and a 200 on a real request.

5. Check what the mislabeled value leaked into

The client ID sent as an API key went into logs, error reports, and possibly URLs. Client IDs are not secrets, so exposure is low-risk, but confirm the real secret was never sent anywhere the client ID was.

Expected: confirmation the real secret stayed out of logs and URLs during the misconfiguration window.

Use this when

• Auth fails silently or with a generic "invalid credentials" after following the docs
• The generated config has one field where the provider dashboard shows two values
• Docs call both the client ID and the secret some variant of "key"
• The value in the auth header looks like an identifier (short, non-random) rather than a secret

Not for this skill when

• The credentials are correct but expired or revoked (different problem)
• The endpoint URL is wrong and every credential fails (check the URL first)
• The provider genuinely uses one value for everything (some do - then nothing is swapped)
• Requests fail with non-auth errors after auth succeeds (downstream problem)

Variant phrasings

docs labeled client_id and API key ambiguously

Same fix. Ambiguous prose is why step 2 uses example requests, not paragraphs, as ground truth.

auth failed silently for a day with no useful error

Silent failures are the signature of this bug: the request is well-formed, the value is simply not a credential. Steps 1 to 3 give you a decision procedure instead of another day of guessing.

Why it happens

Docs writers use "key" loosely for both the public identifier and the private secret, and the agent reads prose as a spec. A client ID and an API key are both opaque strings, so nothing in the generated code looks wrong - the wrong value sits in the right-shaped header and the provider rejects it with a generic error. The ambiguity is invisible until you compare the provider's example request against the generated one.

Edge cases

• Provider wants client ID plus secret in basic auth AND an API key in a header: some providers use both. Step 2's example request reveals this; do not assume one value is enough.
• Dashboard shows multiple API keys: use the one with the right scopes. A valid-but-underprivileged key fails with 403, which looks like this bug but is not.
• The docs' example request is itself stale: if no candidate works, the example may be outdated. Check the provider's changelog or support docs for a credential format change.
• Client ID is genuinely the credential: rare, but some legacy APIs accept the client ID as the key. Step 3's test proves it either way.

Provenance

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

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

Thread query: generated client used the client_id as the API key - the docs labeled them ambiguously and auth failed silently for a day

TL;DR: The client ID is an identifier, not a secret - it names the app, it never authenticates it. Find the provider's real secret (API key, client secret, or token) and put that in the auth header; keep the client ID only where the provider asks for an identifier. One test request per candidate value settles it in minutes.

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

Always send the SearchApi key in the Authorization header instead of the URL. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. You get the same auth with none of the key-in-logs exposure that the query-param form creates.

Fix

1. Always send the SearchApi key in the Authorization header instead of the URL. Expected: You get the expected result; the problem is gone.

2. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. Expected: You get the expected result; the problem is gone.

When to use

• You are setting up or using this SearchApi feature.
• The symptom matches: put the api key in the Authorization header, not the query string.

When NOT to use

• Unrelated SearchApi issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against SearchApi.

Variant phrasings

put the api key in the Authorization header, not the query string

Why it happens

Official docs: the SearchApi docs for the TikTok profile videos engine document two ways to pass the api key, as a query parameter on the URL or in the Authorization header as a bearer value. The docs show the query param form in examples, but every URL with the key in it gets written into server logs, search history, and browser history. The gotcha is that the convenient copy-paste example is the leaky one. Docs: https://www.searchapi.io/docs/tiktok-profile-videos-api

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Official docs: the SearchApi docs for the TikTok profile videos engine document two ways to pass the api key, as a query parameter on the URL or in the Authorization header as a bearer value. The docs show the query param form in examples, but every URL with the key in it gets written into server logs, search history, and browser history. The gotcha is that the convenient copy-paste example is the leaky one. Docs: https://www.searchapi.io/docs/tiktok-profile-videos-api Resolved: always send the SearchApi key in the Authorization header instead of the URL. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. You get the same auth with none of the key-in-logs exposure that the query-param form creates. This matters doubly because SearchApi keeps a search history endpoint: any request you made with the key in the URL sits in your history with the full request URL attached, visible to anyone with account access for 90 days. Source: https://www.searchapi.io/docs/tiktok-profile-videos-api