Proxycurl Employee Listing replacement

Proxycurl's Employee Listing handed you the people at a company from its LinkedIn page. POST /linkedin_company_employees_search does the same thing, takes the company page URL, and pages through the results.

Get 100 free credits — no card

The request shape is small and the billing model is where your attention should go: this endpoint charges per result rather than per call, which changes how you should write the pagination loop.

# Before (Proxycurl) — dead
# GET https://nubela.co/proxycurl/api/linkedin/company/employees/?url=<company-url>
#   -H "Authorization: Bearer $PROXYCURL_KEY"
#

# After (RichAPI)
curl -X POST https://api.richapi.ai/api/v1/linkedin_company_employees_search \
  -H "x-api-key: $RICHAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_linkedin_url": "https://www.linkedin.com/company/example/",
    "page": 1
  }'

company_linkedin_url is required. page is an integer that defaults to 1. That is the whole request. Note the parameter name is not url, unlike the two enrichment endpoints, which is the kind of detail that costs twenty minutes if you copy a working snippet from the wrong page.

{
  "elements": [
    {
      "name": "...",
      "position": "...",
      "linkedinUrl": "https://www.linkedin.com/in/example/"
    }
  ],
  "pagination": {}
}

Each element carries three fields: name, position, and linkedinUrl. That is a directory row, not a person record. To get title history, location or an About section, pass the linkedinUrl into /enrich_profile, which is a separate charge per person.

Until that is confirmed, write the loop to terminate on an empty elements array rather than on a field you assume exists inside pagination. That condition is true whatever the pagination object turns out to hold.

import os, requests

def employees(company_url: str, max_pages: int = 20):
    h = {"x-api-key": os.environ["RICHAPI_KEY"]}
    for page in range(1, max_pages + 1):
        r = requests.post(
            "https://api.richapi.ai/api/v1/linkedin_company_employees_search",
            headers=h,
            json={"company_linkedin_url": company_url, "page": page},
        )
        r.raise_for_status()
        batch = r.json().get("elements") or []
        if not batch:
            return
        yield from batch

The max_pages cap is not defensive clutter. On a per-result endpoint an unbounded loop over a 60,000-person company is a spend decision you made by accident, so make it on purpose with a number in the code.

0.1 credits per result, counted from the elements array, with no flat per-call fee. A page that returns 25 people costs twenty-five times the per-result rate, 2.5 credits. A cost example without a result count is meaningless on this endpoint, which is why every number here carries one.

Work your estimate the same way. Decide how many people you actually need per company, multiply, and stop the loop there. Pulling the first two pages of a large org usually answers the question that made you call the endpoint, and pulling all forty pages rarely does.

This is not a waterfall endpoint and there is no zero-cost-miss guarantee here. Our miss-free claim covers the waterfalls, email finder, email verifier and phone finder, and this is not one of them. 4xx and 5xx cost nothing, as everywhere. Rates are tiered by package size on the pricing page.

The response carries an execution_log showing which sources ran and what came back, which on a company that returns a short list tells you whether the company genuinely has few public employees or a source came up short.

Finding the buying committee inside a target account. You know the company and not the people. Page the list, filter position for the three titles that matter, and enrich only those, which keeps the per-result spend proportional to the deal rather than to the headcount.

Watching where a competitor's team goes. Run the listing on the same company monthly and diff the names. Departures and new hires show up without anyone subscribing to a signals product, and it is your data rather than a vendor's interpretation of it.

Giving an agent an org to work with. Through the hosted MCP server, an agent asks for the people at a company, picks the ones relevant to its task, and enriches those alone. It decides the scope, and per-result billing means the bill follows the decision instead of a flat charge per attempt.

How do I know when to stop paging?
Stop when elements comes back empty, and cap the loop yourself. The pagination object's keys are not documented in the live spec yet, so do not build your exit condition on them.

Does this return email addresses?
No. It returns name, position and linkedinUrl. For a work email, take the profile URL into the email finder, which is a waterfall endpoint and bills zero when it misses.

Can I filter by title or seniority in the request?
Not in this request body, which takes the company URL and a page number. Filter position on your side after the call.

Is this Employee Listing or Employee Search?
One endpoint replaces both Proxycurl paths for the common case of listing people at a known company. If your old integration relied on Proxycurl-side filters, that logic moves into your code.

What does a full org cost me?
Per-result times the number of results you pull. Decide the depth first; that decision is the budget.

Do I need a credit card?
No. 100 free credits on signup, enough to page a couple of companies and see the shape for yourself.

• Proxycurl alternative: the full endpoint map — every endpoint, in one table
• Company Profile Endpoint replacement — enrich the company before you list its people
• Person Profile Endpoint replacement — turn a listed profile URL into a record
• Person Lookup by email replacement — the other direction, email to person
• Email finder API — profile URL to work email, misses bill zero
• All endpoints — the full catalog
• Pricing — credit packages and tier rates

Page one company you know well and check the list against the org chart in your head. Get 100 free credits