Error: No authentication method found

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.

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

Reporter self-solved and documented it (reporter, RowanAldean): two gotchas, (1) EU users must use eu.api.helicone.ai instead of api.helicone.ai (the key was provisioned in an EU region), and (2) the request/query endpoints require a well-formed JSON body from the docs or they return an unhelpful error.

Steps

1. Reporter self-solved and documented it (reporter, RowanAldean): two gotchas, (1) EU users must use eu.api.helicone.ai instead of api.helicone.ai (the key was provisioned in an EU region), and (2) the request/query endpoints require a well-formed JSON body from the docs or they return an unhelpful error. The examples/export typescript script also needs the eu prefix on the target URL.

When to use

You are seeing this: Helicone REST API returns { "error": "No API key found" } for every endpoint, including https://api.helicone.ai/v1/request/query, even with a fresh read/write key, via header and via the https://api.helicone.ai/sk-[key]/... Use this skill when you run into "API not functional - authentication issues even with read key".

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

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://api.helicone.ai/v1/request/query`
• https://api.helicone.ai/sk-[key

In gh:Helicone/helicone#2760 (https://github.com/Helicone/helicone/issues/2760), the question was: Helicone REST API returns { "error": "No API key found" } for every endpoint, including https://api.helicone.ai/v1/request/query, even with a fresh read/write key, via header and via the https://api.helicone.ai/sk-[key]/... URL form. The reporter uses Azure OpenAI through the proxy. The verified resolution: Reporter self-solved and documented it (reporter, RowanAldean): two gotchas, (1) EU users must use eu.api.helicone.ai instead of api.helicone.ai (the key was provisioned in an EU region), and (2) the request/query endpoints require a well-formed JSON body from the docs or they return an unhelpful error. The examples/export typescript script also needs the eu prefix on the target URL.