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

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