DOI resolution failed error 404 doi.org link not found

Not specified by the original author.

TL;DR

deploymentnotfound on Vercel means no deployment is attached to the hostname you opened: the error page shows 404 NOTFOUND with Code DEPLOYMENTNOT_FOUND. The domain was never assigned to the project, the deployment behind the URL was deleted, or the URL is a stale preview link. Fix it by attaching the domain in the project under Settings, Domains, or by promoting a Ready build to Production; redeploying alone does not attach a domain.

404: NOT_FOUND
Code: DEPLOYMENT_NOT_FOUND

Use this when

• A Vercel URL shows 404 NOTFOUND and the code line reads DEPLOYMENTNOT_FOUND
• A custom domain was bought and DNS points at Vercel, but the site never loads
• An old preview or deployment URL that used to work now returns 404

Not for this skill when

• The code is NOTFOUND without DEPLOYMENT in front of it: a deployment is serving but its routes have no match, which is a routing or output problem
• Your own app renders its 404 page: that is your code answering, not Vercel
• The deploy itself failed in the build log: fix the build first, then come back here if the hostname still 404s

Steps

1. Read the code, not just the 404. Open the failing URL and confirm the page shows DEPLOYMENTNOTFOUND, not plain NOT_FOUND.

Expected: you have confirmed which of the two Vercel 404s this is before changing anything.

2. Attach the domain to the project. In the Vercel dashboard open your project, then Settings, then Domains, type the domain and click Add. It takes effect within seconds and does not need a redeploy.

Expected: refreshing the URL loads your site instead of the error page.

3. Check you are opening the right URL. Preview URLs (project-git-branch-team.vercel.app) are ephemeral and die when the branch or project is deleted. Use the production domain, or click Visit on the latest deployment.

Expected: the production URL works even if the bookmarked preview URL does not.

4. Confirm a Ready production deployment exists. Open the Deployments tab. If the latest Production deployment shows Error or Canceled there is nothing to serve; fix the build and redeploy. If a good build exists but is not Production, promote it.

Expected: the Deployments tab shows a Ready build marked Production.

5. If the domain shows as assigned but the error persists, check whose project it is assigned to. A domain can only serve one project; assigned to a different project or team in the same account, it 404s on yours.

Expected: the domain sits on the project you are testing, in the team you are testing.

Variant phrasings

404 notfound code deploymentnot_found

The full error page text as one search string. Same diagnosis and same fix: attach the domain (step 2) or promote a Ready build (step 4).

deployment not found vercel

The plain-words version of the same failure. If Vercel answered the request, the code on the page is DEPLOYMENTNOTFOUND even when the person searching does not quote it.

vercel domain 404 after adding custom domain

Adding DNS records is only half of the setup: until the domain is also added under Settings, Domains on the project, Vercel has nowhere to route it and returns this code.

Root cause

Vercel routes each hostname to one specific deployment. If the domain was never added to the project, was removed, or the deployment the URL pointed at was deleted, the edge has nowhere to send the request and returns DEPLOYMENTNOTFOUND. Redeploying does not attach a domain, which is why people get stuck in a redeploy loop.

Edge cases

• Domain assigned but still 404ing: DNS may still be propagating (up to 24 hours), or the domain is assigned to a different project or team.
• Deployment Protection is on: deployment URLs ask for a Vercel login by design. That is not this error; use the production domain instead.
• The default project.vercel.app name is taken by someone else: pick another project name so the default slug is free.

Tool compatibility

Vercel, all plans (Hobby, Pro, Enterprise), for both vercel.app domains and custom domains. Dashboard steps are the same on every plan.

Related skills

• Vercel Blob client upload: Access denied, provide a valid token - a different Vercel failure, after the deployment itself loads: https://vectle.com/skills/sklk8NXBSuuEqWele64_QODA
• Diagnose timeouts for AI routes deployed on Vercel: https://vectle.com/skills/skl_jxLAo75dHb9lR1SE4WsruQ

Provenance

Built from real deployment writeups documenting this exact failure, linked in the evidence.

Multiple real deployment writeups document this exact failure. One project manual records the troubleshooting entry verbatim: Error: 404: NOT_FOUND Code: DEPLOYMENT_NOT_FOUND, with the diagnosis that DNS is pointing at Vercel fine but Vercel does not know which project to display, and the verified fix: go to the Vercel Dashboard, open the project, Settings -> Domains, type the domain and click Add, then refresh. A second writeup adds the key distinction: read the code on the 404 page, because NOTFOUND means a deployment is serving but the route has no match, while DEPLOYMENTNOTFOUND means no deployment is attached to the hostname at all, fixed by attaching the domain or promoting the right build to Production. Full threads: https://github.com/bgillis99-pixel/final-125111am/blob/HEAD/DEPLOYMENTMANUAL.md and https://github.com/sakshamfit/restaurant/blob/HEAD/DEPLOY.md

Not specified by the original author.

TL;DR

A 404 on every lookup is not a data problem, it is an account or request problem. Check that the API key is live and the plan includes person enrichment, then check that you are sending a valid identifier (work email, not a guess). If some lookups 404 and others work, that is normal coverage. Every lookup 404ing means the requests never had a chance.

clearbit enrichment api 404 person not found on every lookup

Use this when

• The person endpoint 404s on every call, including known-good test emails.
• Company enrichment works but person does not (or vice versa).
• The integration is new and has never returned a hit.

Not for this skill when

• The error is 401. That is authentication, a different fix.
• Some lookups succeed. Partial 404s are coverage, not a bug.

Steps

1. Verify the key and plan: call the person endpoint with your own work email. Verify: if even that 404s, the problem is account-side.
2. Check the dashboard for plan status, credit balance, and whether person enrichment is enabled on the key. Verify: the plan actually includes what you are calling.
3. Confirm the identifier format: person lookup wants a work email (or a LinkedIn-style identifier per the docs), not a name or a personal email. Verify: a well-formed work email is in the request.
4. Test with curl and the exact documented endpoint before blaming your code. Verify: curl reproduces the 404, ruling out client bugs.
5. If the account is good and inputs are valid but everything 404s, contact support with a request ID. Verify: you have a ticket, not a mystery.

Variant phrasings

clearbit person enrichment 404

The endpoint-named search, same account-first diagnosis.

clearbit api person not found always

Frequency phrasing, points at step 1.

clearbit enrichment returns 404

Symptom phrasing, lands on the identifier check.

Compatibility: Clearbit Enrichment API v2. Person coverage varies by region and data partner; universal 404s are never coverage.

Why it happens

The person endpoint 404s when it has no record, which is normal for unknown people. When it 404s for everyone, the usual causes are a key scoped to company-only enrichment, an expired trial, or malformed identifiers that match nothing. The API cannot distinguish "no record" from "bad request shape" beyond the 404, so you have to check the account first.

Edge cases / pitfalls

• Personal emails (gmail, etc.) have thin coverage by design. Test with work emails.
• A 404 still costs nothing, but retrying the same bad identifier in a loop wastes your time, not credits.
• Do not "fix" universal 404s by enriching junk emails harder. Fix the account or the input pipeline.
• If you migrated keys recently, the new key may lack the person scope the old one had.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0H0zWhj-YYAMJrKU4o-mg

Resolved from the public thread: https://vectle.com/posts/pst0H0zWhj-YYAMJrKU4o-mg

Thread query: clearbit enrichment api 404 person not found on every lookup

TL;DR: A 404 on every lookup is not a data problem, it is an account or request problem. Check that the API key is live and the plan includes person enrichment, then check that you are sending a valid identifier (work email, not a guess). If some lookups 404 and others work, that is normal coverage. Every lookup 404ing means the requests never had a chance.

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.