proxycurl 401 invalid api key on person profile endpoint

Not specified by the original author.

TL;DR

The 401 means Proxycurl does not recognize the credential you sent. Send the key as a Bearer token in the Authorization header exactly as documented, confirm the key is active in the dashboard, and check it is not scoped away from the person endpoint. A key that works on company lookup but 401s on person lookup is a scoping problem, not a typo.

proxycurl 401 invalid api key on person profile endpoint

Use this when

• The person profile endpoint returns 401.
• The same key works on other endpoints or used to work.
• You just created or rotated the key.

Not for this skill when

• The error is 404. The key is fine; the profile is missing.
• The error is 402. That is credits, not auth.

Steps

1. Send the header exactly as documented: `your auth header with no extra whitespace or quotes. Verify: a curl with the literal header reproduces or clears the 401.
2. Check the dashboard: the key exists, is active, and is not revoked or expired. Verify: status reads active.
3. Confirm the key has person-endpoint scope. Some keys are issued per product. Verify: the dashboard shows person API enabled for the key.
4. After rotation, allow a few minutes for propagation and update every place the old key was stored. Verify: no stale copies in env files or CI secrets.
5. If the header is exact and the key is active and scoped, contact support with the request timestamp. Verify: you have a support thread, not a guessing loop.

Variant phrasings

proxycurl 401 unauthorized

The short search, same header-first fix.

proxycurl api key not working

Symptom phrasing, points at step 2.

proxycurl person endpoint auth failed

Endpoint phrasing, lands on the scoping check.

Compatibility: Proxycurl API, Bearer auth. Header formatting is the number one cause.

Why it happens

API gateways reject the key before any business logic runs, so a 401 never tells you whether the profile exists. The common causes are mundane: the key pasted with a trailing space, sent as a query param instead of a header, revoked during rotation, or issued without the person product scope. The fix is always in the credential plumbing, never in the lookup.

Edge cases / pitfalls

• Never log the full key when debugging 401s. Log the last four characters.
• Keys in client-side code get harvested and revoked. Server-side only.
• A 401 that appears suddenly on a working key usually means rotation or a billing hold. Check both.
• Do not retry 401s in a tight loop; some gateways rate-limit auth failures and you will add a 429 to the 401.

Provenance

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

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

Thread query: proxycurl 401 invalid api key on person profile endpoint

TL;DR: The 401 means Proxycurl does not recognize the credential you sent. Send the key as a Bearer token in the Authorization header exactly as documented, confirm the key is active in the dashboard, and check it is not scoped away from the person endpoint. A key that works on company lookup but 401s on person lookup is a scoping problem, not a typo.

Not specified by the original author.

TL;DR

A 404 on a profile that used to resolve usually means the person changed their LinkedIn URL slug, made the profile private, or deleted it. Re-resolve the person from a fresh identifier (current work email or name plus company) instead of replaying the stale URL. If the fresh lookup also 404s, the profile is genuinely unreachable and you record that, not retry it forever.

proxycurl 404 profile not found linkedin person moved

Use this when

• A stored LinkedIn URL that once enriched now returns 404.
• The person changed jobs recently.
• Bulk enrichment shows a growing 404 rate on old URLs.

Not for this skill when

• The error is 401. That is auth, unrelated to the profile.
• The URL never worked. That is a bad identifier, not a move.

Steps

1. Confirm the profile is actually gone: open the LinkedIn URL in a browser (logged out is fine). Verify: LinkedIn itself shows the profile as unavailable or redirected.
2. Re-resolve from a fresh identifier: run the lookup with the person's current work email or name plus current company. Verify: the fresh query returns the new profile URL.
3. Update your stored record with the new URL and a resolved-at timestamp. Verify: the next enrichment uses the fresh URL.
4. For bulk lists, re-resolve anything older than 90 days before enriching. Verify: the 404 rate drops on the next run.
5. If the fresh lookup also 404s, mark the person unreachable and move on. Verify: the record is flagged, not retried daily.

Variant phrasings

proxycurl linkedin url 404

The URL-shaped search, same re-resolution fix.

profile not found after job change

Cause phrasing, points at step 2.

proxycurl stale profile url

Age phrasing, lands on the 90-day rule.

Compatibility: Proxycurl person lookup. LinkedIn URL slugs change when people edit their public profile; old slugs die.

Why it happens

Proxycurl resolves the exact URL you give it. LinkedIn lets people change their vanity URL slug, and job changes often trigger profile edits, privacy changes, or deletions. Your database holds the old slug, Proxycurl looks it up faithfully, and LinkedIn answers 404. The data pipeline problem is stale identifiers, not the API.

Edge cases / pitfalls

• Do not guess new slugs by editing the URL. Re-resolve through the API.
• A 404 on a private profile is not a bug; private means private.
• Bulk re-resolution costs credits. Budget it as maintenance, not as a surprise.
• Keep the old URL in history. People sometimes revert slugs, and the history explains the gap.

Provenance

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

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

Thread query: proxycurl 404 profile not found linkedin person moved

TL;DR: A 404 on a profile that used to resolve usually means the person changed their LinkedIn URL slug, made the profile private, or deleted it. Re-resolve the person from a fresh identifier (current work email or name plus company) instead of replaying the stale URL. If the fresh lookup also 404s, the profile is genuinely unreachable and you record that, not retry it forever.

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