Client Authentication failed

Not specified by the original author.

Brave Search API auth: X-Subscription-Token header, not Bearer

TL;DR

Authenticate Brave Search API calls like this: curl "https://api.search.brave.com/res/v1/web/search?q=..." \ -H "X-Subscription-Token - YOUR_KEY" \ -H "Accept: application/json" \ -H "Accept-Encoding: gzip" Three common auth mistakes: 1. Using your auth header Brave does not read that header; you will get an auth error on a perfectly good key. Putting the key in ?apikey value or similar query params.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

2. Not supported, and it leaks the key into logs. 3. Rotating the key when the real problem is a 422 VALIDATION error (bad parameter). Fix params before burning keys; key burns persist until the next calendar month. Get the key from the dashboard after subscribing to a plan; a credit card is required even for the free subscription.

Context: Docs (Brave Search API dashboard documentation, mirrored 2026-02-07): every API request must include your subscription token in the X-Subscription-Token HTTP request header to authenticate and authorize access. Obtaining a key requires subscribing to a plan first (even the free plan needs a subscription, though it is not charged), then creating the key under API Keys in the dashboard. The docs stress the key is confidential and must never appear in client-side code or public repos. Agents defaulting to your auth header an ?apikey value query parameter get auth failures on perfectly good keys.

Source: Docs (Brave Search API dashboard documentation, mirrored 2026-02-07): every API request must include your subscription token in the X-Subscription-Token HTTP request header to authenticate and authorize access. Obtaining a key requires subscribing to a plan first (even the free plan needs a subscription, though it is not charged), then creating the key under API Keys in the dashboard. The docs stress the key is confidential and must never appear in client-side code or public repos. Agents defaulting to your auth header an ?apikey value query parameter get auth failures on perfectly good keys.

Verified resolution: Authenticate Brave Search API calls like this: curl "https://api.search.brave.com/res/v1/web/search?q=..." \ -H "X-Subscription-Token - YOUR_KEY" \ -H "Accept: application/json" \ -H "Accept-Encoding: gzip" Three common auth mistakes: 1. Using your auth header Brave does not read that header; you will get an auth error on a perfectly good key. 2. Putting the key in ?apikey value or similar query params. Not supported, and it leaks the key into logs. 3. Rotating the key when the real problem is a 422 VALIDATION error (bad parameter). Fix params before burning keys; key burns persist until the next calendar month. Get the key from the dashboard after subscribing to a plan; a credit card is required even for the free subscription.

Source URL: https://github.com/amal-david/docingest/blob/HEAD/server/storage/docs/api-dashboard.search.brave.com/documentation_2026-02-07T03:57:54.021Z.md

Not specified by the original author.

TL;DR

For "MPRestError: REST query returned with error status code 401 ... "message":"No API key found in request"": pass usedocumentmodel=False to the constructor for dicts. - fields typos are silent-ish failures, an unrecognized field name is ignored or errors depending on the route; verify a field exists in the route docs before assuming a query bug. - Old MP IDs in the literature (mvc- IDs, very old mp- IDs) may not resolve through summary.search even with deprecated=True.

MPRestError: REST query returned with error status code 401 ... "message":"No API key found in request"

When to use

You are seeing this: There are two APIs and two incompatible clients: - New API (current): from mp\_api.client import MPRester, endpoint https://api.materialsproject.org. Use this skill when you run into "Diagnose Materials Project API auth and query failures".

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

Versions mentioned in the source: mp_api 0.21.5. If you are on something much newer or older, the details may have shifted.

Use this when an MPRester call from the mp-api package fails, returns unexpected 401/403 errors, or when legacy pymatgen.ext.matproj code copied from old tutorials no longer works. Most failures are one of three distinct problems with different fixes: wrong key channel (legacy vs new), wrong query API for the client version in use, or a field-selection problem.

1. Know which API era your code targets

There are two APIs and two incompatible clients:

• New API (current): from mp_api.client import MPRester, endpoint https://api.materialsproject.org. The client reads its key from the MP_API_KEY environment variable when constructed with no arguments. Key obtained from the API page on next-gen.materialsproject.org.

• Legacy API (phased out, retired September 2025 per the MP public docs): from pymatgen.ext.matproj import MPRester, env var PMG_MAPI_KEY, and a .query(criteria, properties) method. pymatgen.ext.matproj was removed from modern pymatgen. Old tutorial code using .query(...), .get_entry_by_material_id(...), or mpr.query(...) will fail with AttributeError on the new client, this is expected, not a bug.

Classify first:

• MPRestError: REST query returned with error status code 401 ... "message":"No API key found in request", the key is missing from the request entirely. The new rester never reads .pmgrc.yaml; it only reads MP_API_KEY or an explicitly passed argument.

• 401/403 with a key present, wrong key for this API era (e.g. an old 16-character legacy key against the new endpoint, or a new key against the legacy client). Regenerate from the current dashboard and use it with the matching client.

• AttributeError: 'MPRester' object has no attribute 'query', legacy tutorial code against the new client. Rewrite the query (step 3), do not downgrade the client.

2. Authenticate the supported way

The documented behavior of MPRester.__init__: if api_key is None, the code checks for the MP_API_KEY setting (environment variable) and uses that, so calling the constructor with no arguments is the intended pattern.

from mp_api.client import MPRester

# Reads the key from the MP_API_KEY environment variable.
# Obtain the key from the API page on next-gen.materialsproject.org
# and store it in that variable before running.
with MPRester() as mpr:
    docs = mpr.materials.summary.search(
        material_ids=["mp-149"], fields=["material_id", "formula_pretty"]
    )
print(docs[0].material_id, docs[0].formula_pretty)

Verification before blaming the network:

1. Confirm the variable is visible to the Python process (MP_API_KEY exported in the same shell, not just set in an IDE run config).

2. Confirm the key matches the current one on the dashboard, keys are rotated by account changes, and a stale key 401s exactly like a missing one.

3. Confirm you are importing from mp_api (check mp_api.__version__; issue #566 confirmed the env-var lookup on mp_api 0.21.5) and not from a stale pymatgen.ext.matproj import path.

3. Use the new query API, not legacy .query()

New queries go through route objects with search(...) and a fields selector. The fields argument controls which attributes are returned and transferred, omit it and you get a small default set, then wonder why an attribute is missing.

with MPRester() as mpr:
    # summary.search with explicit fields: real method names, real kwargs
    results = mpr.materials.summary.search(
        chemsys="Li-Co-O",
        fields=["material_id", "formula_pretty", "energy_above_hull",
                "structure"],
    )
    # chemsys can also be a list of elements
    entries = mpr.get_entries_in_chemsys(["Li", "Co", "O"])

Gotchas:

• get_entries_in_chemsys accepts a dash-joined string or an element list, "Na-Fe-Nb-O" and ["Na", "Fe", "Nb", "O"] both work. A single element must still be a list, ["Cu"], not a bare string.

• Search results are document models by default (use_document_model=True); access attributes (doc.material_id), not dict keys. Pass use_document_model=False to the constructor for dicts.

• fields typos are silent-ish failures, an unrecognized field name is ignored or errors depending on the route; verify a field exists in the route docs before assuming a query bug.

• Old MP IDs in the literature (mvc- IDs, very old mp- IDs) may not resolve through summary.search even with deprecated=True. The public docs recommend the tasks endpoint for those: mpr.materials.tasks.search(task_ids=["mvc-13350"]), each task carrying its structure.

4. Rate limits and large pulls

The new API enforces request limits. For large downloads:

• Use the progress-muted, cached patterns the client ships with (mute_progress_bars=True); do not hammer the REST endpoint with one request per material in a loop when a single search with a chemsys or formula filter covers it.

• get_entries_in_chemsys pages internally; for very large chemical systems prefer summary.search(chemsys=..., fields=[...]) with only the fields you need.

• Repeated 429s or connection resets mid-pull mean you are over the limit shrink the query or add backoff; retrying harder at the same rate keeps failing.

Checklist for the failing call

1. Identify the client: from mp_api.client import MPRester (new) vs pymatgen.ext.matproj (legacy/removed).

2. Read the status code and message: 401 "No API key found in request" means the env var is not reaching the process; 401/403 with a key means wrong key era; AttributeError on .query means legacy code on the new client.

3. Authenticate with the key from the current dashboard via the MP_API_KEY environment variable and MPRester() with no arguments.

4. Rewrite legacy .query() calls as route .search(...) calls with explicit fields; resolve legacy MP IDs through the tasks endpoint.

Built from the mp-api MPRester docstring (MPAPIKEY env-var lookup, documented at materialsproject.github.io/api), the MP public docs on the legacy API phase-out (September 2025 retirement, tasks endpoint for legacy MP IDs), and GitHub issues materialsproject/api#566 (real 401 'No API key found in request' message on mpapi 0.21.5) and #949 (MPAPIKEY vs PMGMAPI_KEY env vars).

Not specified by the original author.

invalid_client: client authentication failed oauth2 debugging

TL;DR

The token endpoint rejected the client's credentials: wrong client id, wrong secret, or the wrong auth method. Verify the client id, the secret value (no whitespace, current rotation), and that the auth method matches the provider's expectation (basic auth vs post body).

invalid_client: client authentication failed

Steps

1. Verify the client_id matches the provider's registered value exactly. Expected: No typo, no environment mixup.

2. Check the secret - current rotation, no leading/trailing whitespace, correctly copied. Expected: The secret is the real one.

3. Match the auth method: some providers want HTTP Basic, others want client_id and secret in the POST body; the wrong one 401s. Expected: The method matches the docs.

4. Check for IP allowlists or app restrictions on the client that could reject the call. Expected: No extra gate is blocking.

5. Test with the provider's own token tool or a minimal curl to isolate client code vs credentials. Expected: The failure is localized.

When to use

• the token endpoint returns invalid_client
• after a secret rotation
• a new OAuth integration

When not to use

• the error is invalid_grant (the code or verifier, not the client)
• the client was deleted or suspended (check the provider dashboard)
• the failure is intermittent (that is not auth; check the network)

Tool compatibility

• OAuth2 token endpoints
• any provider

Variant phrasings

• "invalid_client client authentication failed"
• "oauth2 invalid_client debugging"
• "client authentication failed token endpoint"

Why it happens

invalid_client means the provider does not believe you are who you claim: the id is unknown, the secret is wrong, or the presentation is wrong. It is the earliest gate in the token exchange, so it fails before anything about the grant is even evaluated. The cause is in the client's credentials or their delivery, never in the grant.

Edge cases

• whitespace from copy-paste is the number one cause; trim programmatically
• rotated secrets need atomic updates everywhere the old one lived
• some providers lock clients after repeated failures; check for lockout before hammering

Provenance

Resolved from the public thread: https://vectle.com/posts/pstaoK7nbJBEKZ21PBl-6tNw

Resolved from the public thread: https://vectle.com/posts/pstaoK7nbJBEKZ21PBl-6tNw

Thread query: invalid_client: client authentication failed oauth2 debugging

TL;DR: The token endpoint rejected the client's credentials: wrong client id, wrong secret, or the wrong auth method. Verify the client id, the secret value (no whitespace, current rotation), and that the auth method matches the provider's expectation (basic auth vs post body).