Migrating from Proxycurl to EnvoAPI, endpoint by endpoint

LinkedIn sued Proxycurl in January 2025 over scraping and a network of fake accounts. Proxycurl shut down in July 2025, and the case was resolved with a permanent injunction requiring it to stop accessing LinkedIn and delete the data it had collected. Any pipeline still calling those endpoints is already failing. This guide maps the calls one by one, shows what actually changes in the response, and gives a cutover plan that works now that there is no live provider left to compare against.

What actually changes

Most of the migration is mechanical. Proxycurl was keyed on LinkedIn URLs and returned the record at the top level under snake_case field names; EnvoAPI takes the same URL on its detail endpoints, wraps every response in one envelope, and names fields in camelCase. Nothing about your downstream data model has to change if you put an adapter in the right place.

Endpoint mapping

The /detail endpoints exist precisely for this shape of call: they take the same url parameter your Proxycurl code already passes, so the majority of call sites change only a base URL, a header, and a path.

The full surface is 47 documented endpoints across profiles, companies, search, jobs, and posts. If a Proxycurl call has no single equivalent, it usually composes from two — a company lookup followed by an employee listing, for example.

Changing the request

Authentication moves from a bearer token to the X-API-Key header. Keep the key in the environment, on the server, and out of anything that reaches a browser bundle.

1import os2import requests34# Before — Proxycurl, keyed on the profile URL5requests.get(6    "https://nubela.co/proxycurl/api/v2/linkedin",7    headers={"Authorization": f"Bearer {os.environ['PROXYCURL_KEY']}"},8    params={"url": profile_url},9    timeout=20,10)1112# After — EnvoAPI, same input, different header and path13requests.get(14    "https://api.envoapi.com/api/v2/profiles/detail",15    headers={"X-API-Key": os.environ["ENVO_API_KEY"]},16    params={"url": profile_url},17    timeout=20,18)

Unwrapping the envelope and keeping your contracts

This is where migrations actually go wrong — not on paths, but on the shape underneath them. Every EnvoAPI response carries success, data, pagination, and meta, so the record your code wants is one level down, and failures arrive as meta.error rather than as an exception from the HTTP client. One adapter function at the edge of your system keeps that detail out of every service that consumes it.

1class EnrichmentError(Exception):2    pass345def to_internal_profile(payload: dict) -> dict:6    """Unwrap one EnvoAPI response into the shape our services expect."""7    if not payload.get("success"):8        error = (payload.get("meta") or {}).get("error", {})9        raise EnrichmentError(error.get("type", "unknown"), error.get("detail"))1011    data = payload["data"]12    current = (data.get("currentPositions") or [None])[0] or {}1314    return {15        "first_name": data.get("firstName"),16        "last_name": data.get("lastName"),17        "headline": data.get("headline"),18        "public_identifier": data.get("publicIdentifier"),19        "current_company": current.get("companyName"),20        "current_title": current.get("title"),21    }

A missing field is a state, not a failure. Public data is uneven: treat a null headline or an empty position list as a value your workflow handles, the way it already handles an unresolved record.

Errors and rate limits

Rate limits return 429 with type: rate_limited in meta.error — requests are rejected rather than queued, so the client owns the backoff. Bounded exponential backoff over a few attempts is enough; retry loops without a ceiling turn one slow minute into an outage. The rate limits and errors pages document the response bodies and every error type.

Rolling out without a live provider to compare against

Standard migration advice says run both providers in parallel and diff the results. That is not available here: Proxycurl has been shut down since July 2025, so there is nothing live to compare against. Use what you already stored instead.

• Audit the call sites first — endpoint, monthly volume, and the fields your business logic actually reads. Fields nobody reads do not need mapping.
• Take a sample of records your pipeline enriched through Proxycurl and re-enrich them through EnvoAPI, then diff coverage field by field. Your own historical output is the baseline the dead provider can no longer give you.
• Test the whole thing on the free plan first — it includes 100 credits, which is enough to check coverage on a real sample before any commitment.
• Put the new client behind a feature flag and move traffic in stages, highest-value flows first, so a coverage surprise affects one workflow rather than all of them.
• Watch error rates, latency, and enrichment coverage for a few days per stage, then remove the Proxycurl code paths once the last flag is on.

Prioritise by blast radius: real-time enrichment on a user-facing screen before nightly exports, and anything feeding a customer-visible number before internal dashboards.

What to read while you migrate

• Authentication — where the key goes and how to keep it server-side.
• Rate limits — the 429 body and a bounded backoff example.
• Errors — every error type and what to do about it.
• Pagination — cursors and offsets for list endpoints such as employee listings and search.
• Contact the team if a Proxycurl call in your inventory has no obvious equivalent — the composition is usually two endpoints, and it is worth confirming before you build around a gap.

FAQs about the migration