curl -G \
  "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "first_name=Patrick" \
  --data-urlencode "last_name=Collison" \
  --data-urlencode "employer_website=https://stripe.com" \
  -H "Authorization: Bearer demo-api-key"

If you are building against the LinkedIn API for person profile enrichment, start there.

That demo call hits NinjaPear's Person Profile endpoint through the Employee API. It returns enriched profile data using public web sources and AI extraction, not LinkedIn scraping.

Now the important part.

If you are searching for a LinkedIn People Profile API, there are really two questions you need answered.

First, what can the official LinkedIn API actually do?

Second, when does it stop being the right tool for the job?

I have unusually strong opinions on this because I earned them the expensive way. I used to be the CEO of Proxycurl. We grew it to ~10M ARR and, for a time, it was probably the largest LinkedIn scraping service in the market. I spent years inside the machinery of LinkedIn profile data, official and unofficial. So this guide is not theory. It is the version I wish more developers got on day one.

What the LinkedIn API actually does

LinkedIn shut down broad public API access years ago. If you want meaningful access today, you are dealing with approvals, OAuth scopes, product restrictions, and business qualification.

That does not mean the LinkedIn API is bad. It means it is opinionated. It is designed around LinkedIn's platform interests, not around every enrichment workflow a sales, recruiting, or data product team might want.

At a high level, the official LinkedIn API is still good at a few specific things:

• Sign In with LinkedIn
• member-authorized profile access
• posting and social actions
• organization workflows
• approved partner use cases

If your product needs native LinkedIn functionality, use LinkedIn.

Examples:

• users sign in with LinkedIn
• users post to LinkedIn from your app
• your workflow depends on authenticated member actions
• you are already in an approved LinkedIn program

That is the cleanest use case for the official API. No argument from me.

Where person profile enrichment gets tricky

Most people searching for a LinkedIn API People Profile API are not actually trying to build a LinkedIn app.

They are trying to:

• enrich a lead in a CRM
• find the right buyer at a company
• turn a work email into a usable person profile
• turn a title plus company into an actual human being
• pull professional identity data into an internal workflow

That is a different problem.

When I was running Proxycurl, this was the mistake I saw over and over. Teams said they needed LinkedIn data. What they usually needed was accurate structured professional identity data for person profile enrichment. Those are not the same thing.

The official LinkedIn API can still help, but only within the constraints LinkedIn allows.

What most developers discover

The first trap is simple.

A lot of developers assume Sign In with LinkedIn returns a detailed member profile. Usually it does not. The basic member-authorized flow typically gets you a small set of fields such as:

• first name
• last name
• email address
• profile photo

That is fine for auth. It is weak for enrichment.

And there is a more annoying catch.

Sign In with LinkedIn also does not give you the signed-in user's LinkedIn profile URL, and it does not give you the person's full profile object in the way most developers expect. If your plan is, "I will let the user sign in, grab their LinkedIn profile URL, then use that as the key for person profile enrichment," you are already at a dead end.

This is the part a lot of guides hand-wave away. I will not. For person profile enrichment, auth data is not profile data.

If you need work history, education, social handles, current company context, or a way to resolve a person from role + company, the official LinkedIn API is usually not the easy path people hope it is. It is especially not a good fit if your real requirement is person profile enrichment across prospects or candidates you do not control.

LinkedIn API methods

For profile access, there are really two lanes.

Method 1: 3-legged OAuth

This is the normal member-authorized flow. A user grants your app permission, and you fetch the profile data available to that permission set.

This is useful when a user is inside your app and intentionally connects their own LinkedIn account.

It is not useful if you want to enrich arbitrary prospects at scale.

Method 2: approved profile access

This is the path people usually mean when they talk about the real LinkedIn People/Profile API.

The catch is the catch: approvals, business qualification, product restrictions, and commercial friction.

If you are in recruiting tech, sales tech, or anything adjacent to where LinkedIn has its own product interests, life tends to get more complicated.

Python example: Sign In with LinkedIn

I am keeping this part because the OAuth mechanics are still useful.

import requests
import secrets

LINKEDIN_CLIENT_ID = "your_client_id"
LINKEDIN_CLIENT_SECRET = "your_client_secret"
LINKEDIN_REDIRECT_URI = "https://yourapp.com/callback"


def generate_authorization_url():
    auth_url = "https://www.linkedin.com/oauth/v2/authorization"
    return requests.Request(
        "GET",
        auth_url,
        params={
            "response_type": "code",
            "client_id": LINKEDIN_CLIENT_ID,
            "redirect_uri": LINKEDIN_REDIRECT_URI,
            "state": secrets.token_hex(8).upper(),
            "scope": " ".join(["r_liteprofile", "r_emailaddress"]),
        },
    ).prepare().url


def get_access_token(authorization_code):
    token_url = "https://www.linkedin.com/oauth/v2/accessToken"
    response = requests.post(
        token_url,
        data={
            "grant_type": "authorization_code",
            "code": authorization_code,
            "redirect_uri": LINKEDIN_REDIRECT_URI,
            "client_id": LINKEDIN_CLIENT_ID,
            "client_secret": LINKEDIN_CLIENT_SECRET,
        },
    )
    response.raise_for_status()
    return response.json()["access_token"]


def get_profile(access_token):
    profile_url = "https://api.linkedin.com/v2/me"
    response = requests.get(
        profile_url,
        headers={"Authorization": f"Bearer {access_token}"},
    )
    response.raise_for_status()
    return response.json()

This works for authentication.

It is not what most GTM, recruiting, or enrichment products actually need.

If you are hoping this flow gets you a signed-in member's LinkedIn profile URL plus a rich person record you can use for downstream enrichment, it does not. That is why so many teams burn a week here and then quietly change direction.

Python example: approved LinkedIn profile access

If you are on an approved path that allows broader profile retrieval, the flow looks more like this:

import requests

LINKEDIN_CLIENT_ID = "your_client_id"
LINKEDIN_CLIENT_SECRET = "your_client_secret"


def get_access_token():
    token_url = "https://www.linkedin.com/oauth/v2/accessToken"
    response = requests.post(
        token_url,
        data={
            "grant_type": "client_credentials",
            "client_id": LINKEDIN_CLIENT_ID,
            "client_secret": LINKEDIN_CLIENT_SECRET,
        },
    )
    response.raise_for_status()
    return response.json()["access_token"]


def get_profile(access_token, profile_id):
    profile_url = f"https://api.linkedin.com/v2/people/{profile_id}"
    response = requests.get(
        profile_url,
        headers={
            "Authorization": f"Bearer {access_token}",
            "X-RestLi-Protocol-Version": "2.0.0",
        },
    )
    response.raise_for_status()
    return response.json()

Two caveats.

First, this is conceptually useful, but actual access depends on LinkedIn approvals and product terms.

Second, LinkedIn can be the right platform API and still be the wrong person profile enrichment API for your use case.

What the official LinkedIn API is good at

I want to be precise here, because a lot of content on this topic gets lazy.

The official LinkedIn API is good when all three of these are true:

1. you need official platform support
2. the member is knowingly participating in the workflow
3. the workflow is native to LinkedIn itself

That includes:

• sign-in
• content publishing
• organization-level actions
• approved partner features

If that is your world, do not fight it. Use LinkedIn.

The problems start when developers try to stretch that model into broad outbound enrichment, prospecting, recruiting discovery, or CRM backfill for people who have never touched their product.

That is where people start looking for a person profile enrichment API, even if they use LinkedIn-flavored language to describe it.

Start with NinjaPear's Person Profile Endpoint

Now that we have covered the official LinkedIn API properly, here is the practical alternative for the enrichment use case.

Run this:

curl -G \
  "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "first_name=Patrick" \
  --data-urlencode "last_name=Collison" \
  --data-urlencode "employer_website=https://stripe.com" \
  -H "Authorization: Bearer demo-api-key"

That call hits NinjaPear's Person Profile endpoint through the Employee API.

It returns enriched profile data using public web sources and AI extraction, not LinkedIn scraping.

That distinction matters.

It means you can get the shape of data most people want from a LinkedIn People Profile API, or more specifically a person profile enrichment API, without inheriting the scraping mess that usually comes with it.

Why I am confident saying this

This is where my opinion gets less academic.

I used to run Proxycurl, the company that became one of the best-known LinkedIn scraping businesses in the market. We scaled it to ~10M ARR. For a while, if you were buying LinkedIn profile data from a third party, there was a decent chance you were buying from someone whose architecture rhymed with ours.

So when I say LinkedIn profile data is not just a coding problem, I mean that literally.

It is:

• an access problem
• a scaling problem
• a freshness problem
• a legal problem
• and eventually a business model problem

That is exactly why NinjaPear went in a different direction.

Why scraping LinkedIn gets ugly

This is where I have earned the right to be blunt.

When I hear companies say, "we scrape public LinkedIn profiles at scale," I immediately split them into two buckets:

1. they are serving stale database results
2. they are not only scraping public profiles

That sounds harsh. It is still usually true.

Open an incognito window and visit a public LinkedIn profile. Look at what is actually visible. Recent experience is often censored. Important fields are truncated. Public profile pages are not what they used to be.

So when a vendor says they can always return rich current profile data from public LinkedIn pages only, one of two things is happening:

• they are reading from an old warehouse of previously captured profiles
• they are using login-bound access patterns and calling it public

I am not guessing from the outside. I lived inside this machine for years.

The hard part is not writing a scraper. A good engineer can do that over a weekend.

The hard parts are:

• keeping it alive for years
• keeping quality high under rate pressure
• handling bans, throttles, retries, and account churn
• handling legal and operational risk
• doing all of this at millions of profiles per month

That is why I no longer think "just scrape LinkedIn" is serious advice for most companies.

Why NinjaPear is different

NinjaPear's Employee API does not scrape LinkedIn and will not scrape LinkedIn.

Instead, NinjaPear aggregates professional identity signals from public web sources, then uses AI extraction and entity resolution to turn messy evidence into a clean profile object.

That means you can get the output shape you wanted from a LinkedIn People Profile API without taking on LinkedIn's platform constraints or scraping bottlenecks.

In some cases, you can get more useful workflow data because the source base is broader than LinkedIn alone.

That is the important distinction. NinjaPear is not a LinkedIn clone. It is a person profile enrichment system that happens to solve the same business problem most people think they need LinkedIn for.

NinjaPear Person Profile inputs

This is the practical part.

With NinjaPear, you do not need to start from a LinkedIn URL. In many workflows, that is not even the best input.

You can resolve a person profile in three useful ways:

1. work email
2. name + company
3. role + company

That maps much better to how real teams work.

Work email

This is the cleanest input when you have it.

curl -G \
  "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "work_email=steven@nubela.co" \
  -H "Authorization: Bearer YOUR_API_KEY"

Why it works well:

• work email is a strong identifier
• ambiguity is low
• it fits CRM enrichment and inbound lead flows

Name + company

This is the standard path when you know the person and want a structured profile.

curl -G \
  "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "name=Patrick Collison" \
  --data-urlencode "employer_website=stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

Good for:

• CRM backfills
• prospecting pipelines
• candidate enrichment
• spreadsheet workflows

If you prefer explicit fields, the same lookup pattern also works well as first_name + last_name + employer_website, which is why I used that format in the demo call at the top.

Role + company

This is the input I like most.

You know the title. You know the company. You do not know the person yet.

curl -G \
  "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "role=cto" \
  --data-urlencode "employer_website=delve.co" \
  -H "Authorization: Bearer YOUR_API_KEY"

This is a much better starting point for outbound than poking around the LinkedIn UI and hoping the workflow holds together.

Python example: NinjaPear Person Profile

Here is the Python version using work_email.

import requests

API_KEY = "your_api_key"
API_URL = "https://nubela.co/api/v1/employee/profile"


def get_profile_by_work_email(work_email: str):
    response = requests.get(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={"work_email": work_email},
        timeout=60,
    )
    response.raise_for_status()
    return response.json()


if __name__ == "__main__":
    profile = get_profile_by_work_email("steven@nubela.co")
    print(profile)

Here is name + company.

import requests

API_KEY = "your_api_key"
API_URL = "https://nubela.co/api/v1/employee/profile"


def get_profile_by_name_company(name: str, employer_website: str):
    response = requests.get(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={
            "name": name,
            "employer_website": employer_website,
        },
        timeout=60,
    )
    response.raise_for_status()
    return response.json()

Here is the explicit first_name + last_name + employer_website version that matches the demo.

import requests

API_KEY = "your_api_key"
API_URL = "https://nubela.co/api/v1/employee/profile"


def get_profile_by_name_parts(first_name: str, last_name: str, employer_website: str):
    response = requests.get(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={
            "first_name": first_name,
            "last_name": last_name,
            "employer_website": employer_website,
        },
        timeout=60,
    )
    response.raise_for_status()
    return response.json()


if __name__ == "__main__":
    profile = get_profile_by_name_parts("Patrick", "Collison", "https://stripe.com")
    print(profile)

And role + company.

import requests

API_KEY = "your_api_key"
API_URL = "https://nubela.co/api/v1/employee/profile"


def get_profile_by_role_company(role: str, employer_website: str):
    response = requests.get(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={
            "role": role,
            "employer_website": employer_website,
        },
        timeout=60,
    )
    response.raise_for_status()
    return response.json()

Short. Boring. Good.

That is how an enrichment API should feel.

LinkedIn API vs person profile enrichment API

If we compare the LinkedIn API and NinjaPear specifically for person profile enrichment, my view is straightforward.

Faster to start

NinjaPear's homepage is explicit: 3-day free trial, 10 credits included, no credit card required.

That beats waiting on partner approvals.

Lower legal exposure

This matters more than people like to admit.

If you are not scraping LinkedIn, you are not building your product on top of LinkedIn scraping risk. That is not only a legal simplification. It is an operational simplification.

No account farms. No anti-detection stack. No proxy bill that slowly turns into a second cloud bill.

Better workflow fit

LinkedIn thinks in LinkedIn-shaped primitives. NinjaPear thinks in workflow-shaped primitives.

Examples:

• enrich this work email
• find the CTO at this company
• get a full company profile
• find a verified work email
• find peer contacts across a competitive set

These are business actions, not platform actions.

Useful adjacent endpoints

This is where shallow comparisons usually fail.

It is not enough to ask, "can I get a profile?" You should ask whether you can finish the workflow.

Useful adjacent NinjaPear primitives include:

• Work email finder
• Company profile
• Employee count
• Competitor API
• Customer API
• Supportive for Gmail

That ecosystem matters because person profile enrichment is rarely a one-endpoint problem.

That quote is about email data, but the pattern is universal: stale warehouse data always looks great in a deck and worse in production.

The scaling truth

This is the least sexy part of the article and probably the most useful.

At small scale, almost anything works.

At 200 profiles, your scraper works.
At 2,000, it still sort of works.
At 200,000, you start learning religion.
At millions per month, every lie in your architecture gets exposed.

When we were running Proxycurl, the biggest hidden cost was not the code. It was uncertainty.

You do not know when the source changes. You do not know which access pattern dies next. You do not know when throughput assumptions collapse. You do not know whether your current quality depends on something brittle and semi-private.

That is why I care so much that NinjaPear does not scrape LinkedIn.

The absence of that dependency is not just a compliance talking point. It is a scaling advantage.

It means the business is not forced to keep fighting the same source war forever.

Practical decision framework

Use this if you want the simple version.

Pick the LinkedIn API if

• your product lives inside LinkedIn workflows
• you need authenticated member actions
• you already have, or can realistically get, the required approvals
• official platform support matters more than enrichment breadth

Pick NinjaPear if

• you need person profiles, not LinkedIn buttons
• you care about work_email, name + company, or role + company lookups
• you want to get started immediately
• you want lower legal exposure
• you want adjacent enrichment like work email lookup and company data
• you need a person profile enrichment API rather than a social platform API

Avoid scraper-first architecture if

• your product depends on predictable throughput
• your customers expect stable SLAs
• you are building for the long haul
• you do not want your data pipeline to become a permanent cat-and-mouse job

My honest conclusion

If you came here searching for the LinkedIn API People Profile API, the most useful answer I can give you is this:

The official LinkedIn API is real, and it has valid use cases. But for most person profile enrichment workflows, it is the wrong hill to die on.

I used to be much more willing to brute-force this class of problem. That was my mistake. I spent years too close to the machinery of LinkedIn scraping, and the lesson I took away was not, "get better proxies." Instead, I learned to stop depending on this source unless the business absolutely requires it.

That is exactly why NinjaPear went the direction it did.

You can get person-profile-shaped data through the Employee API, resolve people by work email, name + company, first_name + last_name + company, or role + company, and build the rest of the workflow with adjacent enrichment primitives. No LinkedIn scraping. No pretending public profile pages still contain everything. No bullshit.

If you truly need LinkedIn-native actions, use LinkedIn.

If you want a person profile enrichment API with Python examples and a sane integration path, start with NinjaPear instead. Run the demo call at the top. That will tell you more in 30 seconds than another week of reading LinkedIn partner documentation.

I'm pleased to share that there is now an API playground in the dashboard. Essentially, it mirrors the user interface of Postman, except your API keys are automatically populated in the playground.

This is how the API playground looks like:

Really, I built this for myself because I spend a lot of time testing out NinjaPear API endpoints and I really just want to quickly add new parameters without typing out the full curl command or getting slow LLMs to generate them. And if I find it useful, I'm sure some of you will find it useful as well, particularly those who use NinjaPear via API.

YouTube Monitoring

I'm pleased to also share that we added YouTube channel monitoring to the Company Monitor. Your Company Monitor RSS feed will now include new YouTube videos posted by a company if they have a YouTube channel.

YouTube channel monitoring is enabled by default for new company targets added to the Company Monitor.

Questions? Send me an email at hello@nubela.co!

The data operation costs 1 credit per employee returned, with a base credit cost of 10 credits.

Sample Use-cases

1. DevTools sales — "I sell CI/CD and want to reach Stripe's engineering leadership"

HTTP

GET /api/v1/employee/search?company_website=stripe.com&role=VP of Engineering

Cost: 3 credits | Returned 1 prospect

Why this is powerful: one API call, one decision-maker, work-email + LinkedIn-style profile both prefilled and one click away. Compare to manually scraping LinkedIn for an hour.

2. Cybersecurity sales — "I sell security tooling to large platforms; map Airbnb's entire security org"

HTTP

GET /api/v1/employee/search?company_website=airbnb.com&role=Head of Security

Cost: 44 credits | Returned 42 prospects across the full security buying committee

Top decision-makers:

Plus 37 individual contributors (Staff/Senior Security Engineers, Threat Detection, GRC, Cloud Security Architects, Threat Intel analysts, etc.) — the full security buying committee in one call.

Why this is powerful: The role parameter expands to related variants ("Head of Security" returned CISOs, Directors of Engineering for security, IC security engineers, GRC PMs, threat intel). Sales gets the whole pod, not just the title literally typed.

3. HR Tech sales — "I sell an HRIS / people-ops platform; find the buyer at Notion"

HTTP

GET /api/v1/employee/search?company_website=notion.so&role=VP of People

Cost: 3 credits | Returned 1 prospect

Why this is powerful: Sniper precision. 3 credits, one CPO, ready to outreach.

4. Geo-targeted ABM — "I'm running APAC GTM; find Salesforce's Singapore sales leadership"

HTTP

GET /api/v1/employee/search?company_website=salesforce.com&role=Head of Sales&country=SG

Cost: 5 credits | Returned 3 prospects

Why this is powerful: Mix role + country for region-specific ABM — useful for partner sales, channel managers, or any APAC/EMEA-only GTM motion. Note: I tried the same country=SG filter on shopify.com and got [] (Shopify's SG presence isn't enrichable through this query), which is a useful demo that the filter is real, not just narrative.

5. AI martech sales — "I sell to marketing leaders at AI labs; map OpenAI's marketing org"

HTTP

GET /api/v1/employee/search?company_website=openai.com&role=Head of Marketing

Cost: 17 credits | Returned 15 prospects

Top decision-makers:

Plus 8 more specialists (Product Marketing Lead, Enterprise Field Marketing Lead, GTM Startup Marketing, Regional Marketing leads for India, etc.).

Why this is powerful: The query "Head of Marketing" returned the CMO, the VPs and the niche heads (B2B, International, Integrated, Field). For ABM playbooks targeting a department, you get the whole org chart, not just the C-suite name.

Try it today!

Give the Employee Search Endpoint a try today!

This is what Supportive will look like inside your Gmail. In fact, this is what it looks like within my Gmail:

What is Supportive?

Supportive is a browser addon for Firefox and Chrome (as well as every other browser that supports Chrome-based extensions) that bolts a pane onto your Gmail that opens up every time you open an email thread. It will tell you more about the company you are chatting with and every counterparty within the email thread. It will tell you:

• How big the company is.
• Where it is located.
• Who the person you are talking to is: his role, his educational background, and where he is from.
• What the company does.
• And more!

For those who have a little gray in the scalp like I do, you'd remember Rapportive, which NinjaPear is very much inspired by, before LinkedIn acquired and destroyed them.

How does it work?

The browser extension uses InboxSDK, which allows us to extend and interact with Gmail threads. Whenever you, the user, open an email thread, the browser extension takes every email sender, including CC'd emails, and pulls their profile data via the Person Profile API Endpoint and company details (from the sender's email domain) via the Company Details API Endpoint, and has the profile data displayed right within Gmail. No googling needed. Straightforward.

Invite Everyone! It will not cost more.

Because we implemented caching, it means you will not be charged repeatedly for pulling the same company or person profile every time you open an email thread sent by a user you have seen before. Not just you, but everyone within your company will not be charged.

It does not cost extra to invite your teammates to use NinjaPear, and everyone uses the same pool of credits within an account. So invite your team members to NinjaPear today and get them to download Supportive! Your cached profile data will show up for your teammates too!

How much does it cost?

It does not cost extra to use NinjaPear. In fact, your first 50 enrichments are free. An enrichment is an API call.

Thereafter, every API call will be charged as a regular API call.

Where is Supportive Headed?

In the near future, I am going to do two things:

1. You can build and customize your own profiles for yourself and your company within Supportive, so your audience knows who you are.
2. We are going to build Supportive for Microsoft Outlook/365.

I have said this since day 1 of building NinjaPear, that we intend to become the dominant first-party B2B data platform, and this is yet another gentle step in our journey of building the world's first-party competitive intelligence B2B data platform.

Download Supportive on Chrome or Firefox and add profiles into your Gmail!

I designed and built the NinjaPear Prospector because it bothered me that most NinjaPear users are API users. Surely there are people who would be intrigued by the data and just need a quick export, and do not want to write code. What if NinjaPear was just too hard to use?

Prospector Design Process

Spreadsheet Paradigm

There are universal paradigms that everyone is familiar with:

• Spreadsheets - Clay, Excel, Google Sheets
• Kanban - Trello
• Text editing - Claude, WhatsApp, Microsoft Word
• Slides - PowerPoint

Given the success of Clay, the spreadsheet paradigm was an immediate fit for the Prospector.

Sheet-level Actions, Sheet Types, and Column Actions

But a few problems remained. Data isn't always flat, and that means the spreadsheet isn't always an obvious fit. For example, a detailed company profile might contain multiple addresses per company. Or a person profile would have multiple work history records. How can we represent this data as a row (or multiple rows) in a spreadsheet?

To solve the problem of nested data structures, we employed two methods:

1. Sheet-level actions, and
2. Sheet types.

Sheet-level actions allow you to fetch a specific data type which spans multiple rows per record from a parent spreadsheet into a child spreadsheet that will contain the subsidiary data. For example, you can get a new spreadsheet of "Work History" out of a spreadsheet of people profiles.

And because Work History has different data columns than people profiles, they get their own "type" of spreadsheet. Hence, sheet types.

There is also data that we return that is scalar in nature. For example, the employee count of a company. These belong as regular enrichable columns in the Company Sheets. And these regular scalar data operations come in the form of the more commonly accepted "+ Column" actions that we are familiar with in regular spreadsheets.

Streaming Results

On top of that, our data pipeline process is a live enrichment process. We are not reading off a database, so our users—you—get the freshest data possible. This means it takes time to enrich one record at a time, ranging from around 10 seconds per company/person profile to about a minute for similar people records. How can we bulk enrich a spreadsheet with many rows without keeping the user waiting? What if the user closes the spreadsheet tab while waiting?

To solve this problem, we do two things:

1. All sheet-level data operations go into the backend and are operated on asynchronously.
2. Results are streamed back row by row.

So while the whole spreadsheet might take some time to fully enrich, the user will actually see that things are moving in the background.

In fact, the user is given the option to abort the bulk background enrichment anytime in the UI, and—poof—it shuts off. People make mistakes; we need to allow people to stop their credits from being burnt.

Export as CSV or XLSX

And when you are done with the enrichment, you can download the enriched spreadsheet into your favourite CSV/XLSX format.

Getting Started with the Prospector

You can get started with the Prospector in NinjaPear's dashboard here. Give it a try! You no longer need to use the API to build up datasets, particularly for one-time quick enrichments.

The Prospector is a very new and raw feature and is not battle-tested. If you come across any bugs, do send over a bug report to hello@nubela.co. I look forward to having more non-API users adopt NinjaPear into their B2B data enrichment toolset!

Rate Limits

Let's start with the bad news first. I have implemented rate limits and also reduced them.

Rate limits are now live in NinjaPear. While rate limits are documented in our API documentation, they were never fully implemented, mostly because we did not have many users. Three months in, there have been a handful of instances where the NinjaPear service was taken down by a sudden deluge of concurrent API requests. In fact, it literally just happened.

I have also reduced rate limits from 300 requests/minute to 50 requests/minute for API endpoints that you pay for with credits. For the most part, almost no one will be affected other than a handful of you.

What has been nerfed severely are the free API endpoints, such as the Company Logo API or the Disposable Email Checker API. These free tools will now have a rate limit of 2 requests/minute for free/trial tiers.

To sustainably provide free APIs, the rate limit for free APIs now depends on your subscription plan:

• Free, trial, or PAYG plan: 2 requests/min
• $49/mo plan: 20 requests/min
• $299/mo plan: 50 requests/min
• $899/mo plan: 100 requests/min
• $1899/mo plan: 300 requests/min

The free API rate limit applies to Company Logo, Disposable Email Checker, View Credit Balance, and RSS feed consumption.

Sorry about this. These free API requests were consuming compute resources that weren't doing anything for us—no marketing, no attribution, and no user growth—while causing a couple of downtime issues. So, I made a conscious decision to stop supporting users who do not pay us. That said, if you're on a subscription—as many of you are—feel free to enjoy our free services, which will continue to cost you zero credits!

Caching

On to the good news! There is now a user-controllable caching system which will:

1. Reduce the latency of cached responses
2. Reduce your credit usage
3. Allow you to manage profile freshness

For the following API endpoints, there is now a use_cache parameter:

The use_cache parameter controls the freshness of the data you receive, with the side effect of reducing your credit costs. This is how it works and the values that the use_cache parameter accepts:

• use_cache=if-recent — Returns a response no older than 29 days (the freshness window might differ, but most API endpoints use 29 days). If you paid for the initial fresh response, calling the same API endpoint with the same parameters any time within those 29 days will return the cached value at no additional credit cost.
  • This is perfect for cases where you want "fresh-ish" data and might need to call it repeatedly from the cache with as little latency as possible without incurring additional costs.
• use_cache=if-present — Returns a cached response if it exists in the cache. You only pay the first time you fetch it. Thereafter, you do not have to pay for it as long as the response remains in the cache (which is ideally forever).
  • This is perfect for cases when you do not care about freshness or want to minimize cost while getting results as fast as possible.
• use_cache=never — Never use the cache! This always performs a live enrichment, and you will be charged every time.

With this update, the average user is expected to spend less on NinjaPear.

Cache control for the win.

The use_cache lore

I used to run Proxycurl, the largest LinkedIn scraper. We implemented the use_cache parameter because there was a subset of popular profiles that were constantly being requested. The Pareto principle applies. We did not want to keep hitting LinkedIn with the same scraping request, so we implemented the use_cache parameter to limit hits to one profile scrape per month, at most. We never allowed users to have live enrichment at will because that would expose our scraping methodology or resources.

Of course, internally, we had a secret parameter that forced a live LinkedIn scrape, which we used for debugging our data extraction pipeline since LinkedIn changes their website all the time!

Now that we do not scrape LinkedIn, we offer live enrichment as an option at all times with no additional cost! Now you know :)

Part 2 Updates Tomorrow

I will not flood you with too many changes in one update; I will share Part 2 tomorrow. Oh, and there is also a good reason why I implemented the use_cache parameter: latency. We needed good data-retrieval latency for a hot feature that we will be announcing soon.

I will keep you posted!

As usual, if you have any questions, shoot me an email at hello@nubela.co! I reply to all emails personally!

LinkedIn people search still works when the query is simple and specific. In this guide, I’m going to show you the five search workflows that still hold up: search by name, name plus company, name plus location, role plus company, and role plus location. I’ll also show you where LinkedIn search gets weak, what to do after you find the right person, and when to stop doing this manually.

Why this still matters

Most people using LinkedIn people search are trying to find one actual person.

Usually that means one of these:

• a recruiter finding candidates
• a sales rep finding the right buyer
• a founder finding investors or operators
• a journalist verifying a person before outreach

There are still two real routes:

1. Search inside LinkedIn.
2. Search on Google and land on LinkedIn anyway.

This guide keeps the five workflows from our older LinkedIn people search post, because that piece got the practical part right.

Search by name

Use this when you know the exact person’s full name.

Step by step

1. Type the full name into LinkedIn search.
2. Click the People tab.
3. If results are messy, wrap the full name in quotes.
4. Scan the tighter result set.

If the name is still too common after quotes, do not keep scrolling. Add company or location.

Search by name and company

Use this when you know the name and the employer.

Step by step

1. Search the person’s name.
2. Add the company name.
3. Look for the employer context directly in the result.

If you know the company, use it. This is the fastest way to confirm the right person.

Search by name and location

Use this when the name alone is not unique enough.

Step by step

1. Search the name first.
2. Add a location filter or location keyword.
3. Review the narrower list.

Location usually cuts the result set faster than vague title words.

Search by role and company

Use this when you want employees at one company with a specific title.

Step by step

1. Put the multi-word title in quotes.
2. Add the company with AND.
3. Review the results for current title plus company matches.

Search:

"software engineer" AND apple

That is still the cleanest move for this workflow.

That complaint is fair. Broad search gets sloppy fast. Quotes plus Boolean still help.

Search by role and location

Use this when you want to find a type of person in a geography, like founders in a city or region.

Step by step

1. Start with a broad role cluster.
2. Filter by location.
3. Spot the junk.
4. Exclude it with NOT.

Start with:

tech AND founder

Then tighten with either:

NOT investor AND (tech AND founder)

or:

NOT investor AND tech AND founder

What to do after you find them

Finding the profile is not the finish line.

Usually the next question is one of these:

• did I find the right person?
• are they still at that company?
• do I need one profile or a lot of them?
• am I going to repeat this every week?

If it is one person once, manual LinkedIn is enough.

If it is a repeated workflow, manual LinkedIn people search turns into dumb labor fast.

Beware the search limit

Our older LinkedIn people search post warned about this, and the warning still stands: if you do a lot of profile clicking and repeated employee hunting, LinkedIn search gets annoying fast.

The old guide showed both the vague monthly-search warning and the hard stop screen. Here they are, because this part has not gotten friendlier.

LinkedIn’s help page says you can enter “your keyword(s) or a natural language query” and include company, role, title, or location directly in the search bar. The same page also says: “Don't use any quotes in your search query, because natural language search does not support quotes. If you prefer exact keyword matching, you can use Boolean search instead.” That is why quotes and Boolean still matter in this guide.

LinkedIn’s relevance documentation also says people-search results are personalized and “unique to each member” based on the query and the searcher’s context. That means the same query can rank differently for different users.

That is fine for browsing. It is bad for repeatable systems.

Search at scale instead

The old article recommended Proxycurl. That recommendation is dead, because Proxycurl is dead. The shutdown note is here: Goodbye Proxycurl.

So here is the modern recommendation plainly: use NinjaPear when LinkedIn people search stops being a one-off task and starts becoming a repeated process.

NinjaPear is not LinkedIn search. Good. It gives you people search and employee search via API from public web sources, and its docs are explicit that it does not scrape social media platforms. That matters. If you want the legal angle spelled out, read Steven’s piece on whether scraping LinkedIn is legal in 2026. Building an important workflow on legal gray crap is a bad idea.

Here is the practical decision table.

Use Person Profile for one person

Use the Person Profile Endpoint when you already know roughly who the person is and want a structured answer.

Good inputs:

• work email
• name + company
• role + company

Short example:

curl -G "https://nubela.co/api/v1/employee/profile" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  --data-urlencode "name=Patrick Collison" \
  --data-urlencode "employer_website=stripe.com"

What this does: it resolves one person from name + company and returns a structured profile instead of a messy search page.

Use Employee Search for many people

Use the Employee Search Endpoint when you want many current employees at a company and need a repeatable workflow.

This is the upgrade path for:

• recruiting into one account
• sales prospecting into a target company
• market mapping a team
• repeating the same role search every week

Short example:

curl -G "https://nubela.co/api/v1/employee/search" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  --data-urlencode "company=apple.com" \
  --data-urlencode "role=software engineer" \
  --data-urlencode "page_size=10"

What this does: it searches for employees at one company by role and gives you structured results you can reuse.

That is the key difference. Manual LinkedIn search gives you a browsing experience. NinjaPear gives you a repeatable system.

My final recommendation

Use manual LinkedIn people search when you need one person and you need them now.

Use Person Profile Endpoint when you want a structured profile for one person.

Use Employee Search Endpoint when you need many people at one company.

And if you are repeating the same LinkedIn people search every week, stop doing that to yourself. Move the workflow into NinjaPear and get on with your week.

I am the founder of Proxycurl, and if you do not know it yet, I have shut Proxycurl down and NinjaPear is what comes after Proxycurl. If you are searching for proxycurl api in 2026, the practical question is not whether it still works. It does not. The practical question is which Proxycurl API workflow you were trying to use, and whether NinjaPear now solves that workflow better. This guide covers the status, the old API groups, why the product was killed, and the technical replacement paths I would use now.

Why was Proxycurl shut down?

Proxycurl was shut down because LinkedIn sued us in January 2025. I wrote that in the shutdown post: "In January earlier this year (2025), LinkedIn filed a lawsuit against Proxycurl. Today, we are shutting Proxycurl down."

Even though we settled, we do not want customers to carry a legal risk forward with an adversary like LinkedIn with near unlimited resources. That is why NinjaPear exists.

What Proxycurl API is now

Proxycurl is shut down. Old docs, old blog posts, and old code samples still exist. Treat them as historical reference only.

What was Proxycurl API?

Proxycurl API was a set of developer APIs for getting structured people and company data, much of it keyed off LinkedIn URLs as the canonical identifier for entities, people or companies. As the founder, I have got to be honest: ~50% of revenue came from scraping LinkedIn. That is exactly why the legal risk was existential.

The simplest way to understand Proxycurl is by the jobs each endpoint did.

• Get a person’s structured professional profile from a LinkedIn URL with the Person Profile Endpoint.
• Resolve a person from a name plus company with the Person Lookup Endpoint.
• Find the likely decision maker at a company with the Role Lookup Endpoint.
• Search for people with filters like country, past company, and title with the Person Search Endpoint.
• Get a company’s structured profile from its LinkedIn company URL with the Company Profile Endpoint.
• Resolve a company from its name with the Company Lookup Endpoint.
• Get the employee count of a company with the Employee Count Endpoint.
• Get a company logo with the Company Profile Picture Endpoint.
• List current or past employees of a company with the Employee Listing Endpoint.
• Count how many employees a company had in the public dataset with the Employee Listing Count Endpoint.
• Search employees inside a company with the Employee Search Endpoint.
• Find a work email with the Work Email Lookup Endpoint.
• Reverse a work email back to a person or company with the Reverse Work Email Lookup Endpoint.
• Find a personal email with the Personal Email Lookup Endpoint.
• Find a personal phone number with the Personal Contact Number Lookup Endpoint.
• Get a person’s profile picture with the Person Profile Picture Endpoint.
• Run lightweight checks such as disposable email detection with utility endpoints.

That was the real product. A pile of specific endpoints developers used to enrich CRMs, build outbound tools, source candidates, and power internal search.

The API groups and endpoints

People API

The People API handled person resolution, enrichment, search, and profile assets.

Representative endpoints:

• Person Profile Endpoint
• Person Lookup Endpoint
• Role Lookup Endpoint
• Person Search Endpoint
• Person Profile Picture Endpoint

What engineers used it for:

• enrich a lead from a LinkedIn URL
• turn a name plus company into a canonical profile
• find a VP Sales, CTO, or recruiter at a target account
• search for prospects by role history or geography
• add a profile photo to a UI

Why it worked: the response shape was simple, the docs were clear, and the LinkedIn URL made a convenient canonical key.

Why it was fragile: if the canonical object in your architecture is a LinkedIn URL, your whole system is downstream of LinkedIn.

Company API

The Company API handled company identity, enrichment, and count-style lookups.

Representative endpoints:

• Company Profile Endpoint
• Company Lookup Endpoint
• Employee Count Endpoint
• Company Profile Picture Endpoint

What engineers used it for:

• enrich company records in a CRM
• estimate account size before routing or scoring
• attach company logos to records
• resolve messy company names to a canonical entity

This part of Proxycurl was less dramatic than the people side. The object was the company. But the same dependency still sat underneath when LinkedIn company URLs were part of the workflow.

Contact API

The Contact API handled reachability.

Representative endpoints:

• Work Email Lookup Endpoint
• Reverse Work Email Lookup Endpoint
• Personal Email Lookup Endpoint
• Personal Contact Number Lookup Endpoint

What engineers used it for:

• append work email to a lead
• find a personal fallback email
• add a phone number to an outbound sequence
• reverse-resolve an email already sitting in a CRM

One technical point matters here: these fields were not literally scraped from LinkedIn profiles. They came from other sources tied back to the identity object.

Employee Listing API

This was one of the most commercially useful parts of Proxycurl.

Representative endpoints:

• Employee Listing Endpoint
• Employee Listing Count Endpoint
• Employee Search Endpoint

What engineers used it for:

• list employees at a target account
• find current or past employees of a competitor
• build account plans around named people
• source candidates from specific orgs

The economics were explicit in old docs. Employee Listing was priced at 5 credits per employee returned with a 10-credit minimum. Employee Listing Count was 10 credits per call. That alone tells you this was a heavy endpoint backed by heavy infrastructure.

Search API

The Search API was the headless prospecting surface.

Representative endpoints:

• Person Search Endpoint
• Company Search Endpoint

What engineers used it for:

• build prospect lists from filters
• source candidates from competitor companies
• create segments by role, geo, or experience
• power search inside internal tools

One Proxycurl write-up referenced 46 filters on Person Search. That is why people liked it. You could treat it like programmable Sales Navigator.

Utility endpoints

These were the small but useful endpoints.

Representative endpoints:

• Person Profile Picture Endpoint
• Company Profile Picture Endpoint
• disposable email checks
• smaller validation helpers

What engineers used them for:

• clean up product UI
• block throwaway signups
• enrich records without paying for a bigger call

NinjaPear API comes after Proxycurl API, by the same founder

NinjaPear is the API platform I built after Proxycurl.

It does not scrape LinkedIn.

It is built around different primitives:

• companies
• employees from public sources
• customers
• competitors
• updates and monitoring feeds

The easiest way to understand NinjaPear is the same way.

• Get a list of customers, investors, and partners of any company with the Customer Listing Endpoint.
• Find competitors of any company and why they compete with the Competitor Listing Endpoint.
• Get the logo of any company for free with the Company Logo Endpoint.
• Get full company details like industry, description, executives, and office locations with the Company Details Endpoint.
• Get the employee count of any company with the Employee Count Endpoint.
• Get recent blog posts and social media updates of any company with the Company Updates Endpoint.
• Get the full funding history and investors of any company with the Company Funding Endpoint.
• Resolve a company name to its canonical website URL with the Website Lookup Endpoint.
• Find the work email of a person given their name and company domain with the Work Email Endpoint.
• Look up a person's profile, job history, and education from their work email with the Person Profile Endpoint.
• Find people similar to a target person, same role at competing companies, with the Similar People Endpoint.
• Check if an email address is disposable or from a free email provider with the Disposable Email Checker Endpoint.
• Monitor companies for new blog posts, tweets, and website changes via RSS with the Monitor API.
• Check your remaining API credits with the View Credit Balance Endpoint.

Current product surfaces shown on the site include Customer API, Company API, Employee API, Monitor API, and Competitor API.

A few current numbers matter:

• Company Details: 2 credits per call
• Employee Count: 2 credits per call
• Company Updates: 2 credits per call
• Company Funding: 2+ credits per call
• Customer Listing: 1 credit per request + 2 credits per customer returned
• 3-day free trial: 10 credits included

This is a broader data model than Proxycurl had. The first object is usually the company website, not the LinkedIn URL.

Is NinjaPear API the same as Proxycurl API?

No.

Here is the comparison that matters.

And here is the endpoint-level view.

The important part is this: NinjaPear solves many of the same business jobs, but it does not do so by pretending LinkedIn is the center of the universe.

What you should build now

If your old use case was person enrichment

Use the Employee API when the real need is to identify a professional from public signals and return work history, education, location, bio, and social presence.

NinjaPear published launch match-rate data for this endpoint:

If you have a work email, use it. That is the cleanest identity anchor.

curl -G "https://nubela.co/api/v1/employee/profile" \
  --data-urlencode "work_email=[email protected]" \
  -H "Authorization: Bearer YOUR_API_KEY"

import ninjapear

configuration = ninjapear.Configuration(
    host="https://nubela.co",
    access_token="YOUR_API_KEY",
)

with ninjapear.ApiClient(configuration) as api_client:
    api = ninjapear.EmployeeAPIApi(api_client)
    response = api.get_person_profile(work_email="[email protected]")
    print(response)

const NinjaPear = require("ninjapear");
const defaultClient = NinjaPear.ApiClient.instance;
defaultClient.authentications["bearerAuth"].accessToken = "YOUR_API_KEY";

const api = new NinjaPear.EmployeeAPIApi();
api.getPersonProfile({ workEmail: "[email protected]" }).then((data) => {
  console.log(data);
});

If your old use case was company enrichment

Use the Company API.

Current company endpoints on the site include:

• GET /api/v1/company/details
• GET /api/v1/company/employee-count
• GET /api/v1/company/updates
• GET /api/v1/company/funding

curl -G "https://nubela.co/api/v1/company/details" \
  --data-urlencode "website=https://stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

import ninjapear

configuration = ninjapear.Configuration(
    host="https://nubela.co",
    access_token="YOUR_API_KEY",
)

with ninjapear.ApiClient(configuration) as api_client:
    api = ninjapear.CompanyAPIApi(api_client)
    response = api.get_company_details(website="https://stripe.com")
    print(response)

const NinjaPear = require("ninjapear");
const defaultClient = NinjaPear.ApiClient.instance;
defaultClient.authentications["bearerAuth"].accessToken = "YOUR_API_KEY";

const api = new NinjaPear.CompanyAPIApi();
api.getCompanyDetails("https://stripe.com").then((data) => {
  console.log(data);
});

If your old use case was employee listing

Be honest about what you actually need.

If you need a pixel-perfect public LinkedIn roster, NinjaPear is not that.

If you need to identify relevant people at a company with lower legal risk, use:

• Employee API for person-level enrichment
• Company API for company context
• Customer and Competitor APIs if the real job is account selection, not staff enumeration

This is where a lot of teams fool themselves. They ask for an employee list when what they really need is a way to find buying committees.

If your old use case was buyer discovery

Use relationship data instead of profile search as the center of your architecture.

With NinjaPear, you can start from:

• customer lists
• investors
• partners and platforms
• competitors by SEO overlap
• competitors by product category overlap

curl -G "https://nubela.co/api/v1/customer/listing" \
  --data-urlencode "website=https://shopify.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

import ninjapear

configuration = ninjapear.Configuration(
    host="https://nubela.co",
    access_token="YOUR_API_KEY",
)

with ninjapear.ApiClient(configuration) as api_client:
    api = ninjapear.CustomerAPIApi(api_client)
    response = api.get_customer_listing(website="https://shopify.com")
    print(response)

const NinjaPear = require("ninjapear");
const defaultClient = NinjaPear.ApiClient.instance;
defaultClient.authentications["bearerAuth"].accessToken = "YOUR_API_KEY";

const api = new NinjaPear.CustomerAPIApi();
api.getCustomerListing("https://shopify.com").then((data) => {
  console.log(data);
});

This is a better GTM primitive most of the time. Customer graphs and competitor graphs tell you where to fish. A scraped profile usually just tells you who is in the water.

If your old use case was timing signals

Use Monitor API or Company Monitor.

NinjaPear’s public Company Monitor page shows three monitored source types:

• blog posts
• website changes
• X posts

curl -G "https://nubela.co/api/v1/company/updates" \
  --data-urlencode "website=https://stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

import ninjapear

configuration = ninjapear.Configuration(
    host="https://nubela.co",
    access_token="YOUR_API_KEY",
)

with ninjapear.ApiClient(configuration) as api_client:
    api = ninjapear.CompanyAPIApi(api_client)
    response = api.get_company_updates(website="https://stripe.com")
    print(response)

const NinjaPear = require("ninjapear");
const defaultClient = NinjaPear.ApiClient.instance;
defaultClient.authentications["bearerAuth"].accessToken = "YOUR_API_KEY";

const api = new NinjaPear.CompanyAPIApi();
api.getCompanyUpdates("https://stripe.com").then((data) => {
  console.log(data);
});

For sales teams and competitive-intel teams, that is often better than polling stale profile objects and pretending that is intent data.

FAQ

Is Proxycurl API still available?

No.

Why was Proxycurl API shut down?

Because LinkedIn sued Proxycurl in 2025. We settled, and I do not want customers carrying that legal risk forward.

Can I still use old Proxycurl docs?

Only as historical reference.

Is NinjaPear API a direct replacement?

No.

Does NinjaPear scrape LinkedIn?

No. NinjaPear states that employee data is publicly sourced and that it does not scrape professional social media platforms.

Can NinjaPear solve the same use cases?

Often yes, but usually with different primitives: employee profiles from public sources, company details, customer graphs, competitor data, and update feeds.

What if I only wanted job-change or account signals?

Use Monitor API or Company Monitor.

If you are searching for proxycurl api in 2026, the answer is simple. Proxycurl is shut down. If your real need today is company intelligence, employee enrichment from public sources, customer relationships, competitor mapping, or account monitoring, build on NinjaPear. I built Proxycurl, I shut it down, and NinjaPear is the system I built after learning exactly where Proxycurl broke.

If you searched for data enrichment api, you probably want a ranked answer, not a definition. You want to know which API is worth wiring into your system, what it costs, where the data goes stale, and which products create extra implementation work later. My answer is NinjaPear. Not because it wins every subcategory, but because it combines company data, employee data, relationship data, change monitoring, and unusually strong AI-agent readiness in one product.

That is the real buying problem: drift and workflow fit.

Quick rankings

Here is the ranked list first.

1. NinjaPear
2. EnrichmentAPI
3. People Data Labs
4. Apollo
5. Clearbit
6. ZoomInfo
7. FullContact
8. Hunter
9. Clay
10. Crunchbase
11. Cognism
12. RocketReach
13. UpLead
14. Dropcontact
15. Clearout
16. Snov.io
17. Lusha
18. ContactOut
19. LeadMagic
20. Kaspr
21. Prospeo
22. Adapt.io
23. Seamless.AI
24. Datagma
25. Coresignal

This lines up with how many buyers already scan the market.

That shortlist is reasonable. It is also incomplete.

The real split in 2026 is this:

• dataset vendors
• live enrichment vendors
• prospecting tools with an API attached
• intelligence products that also track what changed

Those are not the same thing. Buyers still compare them like they are.

How I ranked them

I used seven dimensions:

1. Freshness
2. Richness
3. Scalability
4. Pricing clarity
5. Developer friendliness
6. Stability
7. AI readiness

Freshness is obvious. Old data degrades quickly.

Richness is not about who has the longest field list. It is whether the returned fields help you do real work.

Scalability is whether I would trust the product inside a system, not whether the vendor sells to large companies.

Pricing clarity matters because hidden pricing usually means forecasting pain, longer sales cycles, or both.

Developer friendliness is docs, schemas, errors, auth flow, rate limits, timeout behavior, and how messy the async model gets.

Stability is whether the product feels like dependable infrastructure.

AI readiness is now part of API quality. If your docs are hard for Claude, Cursor, Codex, or ChatGPT to ingest, integration gets slower.

Pricing table

Pricing belongs near the top because this is where vendors either respect your time or don’t.

If a company hides pricing, I count that against them. Not because every custom contract is bad. Because in a category this mature, hiding entry-level economics is usually a sign that evaluation will be slower and harder than it needs to be.

A few takeaways:

• NinjaPear, EnrichmentAPI, Hunter, Clearout, LeadMagic, Prospeo, and Datagma let you estimate cost without a sales call.
• Clearbit, ZoomInfo, and FullContact lose points because hidden pricing slows evaluation.
• Apollo, Clay, Cognism, and RocketReach sit in the middle: enough public info to get interested, not enough to forecast neatly.

1. NinjaPear

What it does

NinjaPear ranks first because it does more than one-time append. Company details. Employee profiles. Customer relationships. Competitors. Monitoring. That last part matters because after enrichment, the next operational question is usually what changed.

How I scored it

I scored freshness 5/5 because the public product and docs are built around current company intelligence plus ongoing updates, not just static appends. I scored richness 4/5 because it covers company, employee, relationship, and monitoring data, but it is not pretending to be a universal contact database. Dev-friendliness is 5/5 because the docs expose Markdown docs, llms.txt, OpenAPI, SDKs, rate-limit guidance, timeout guidance, and explicit error codes. AI readiness is 5/5 because it is the only vendor here with clear public evidence across all five AI criteria.

Pricing

3-day free trial with 10 credits. Public tiers at $49, $299, $899, and $1,899 per month. PAYG credits last 18 months. Subscriptions come with a 12-month commitment. Customer Listing is 1 credit per request + 2 credits per customer returned.

AI dimension

• AI Skill: Yes
• MCP or agent path: Yes
• Markdown docs: Yes
• llms.txt: Yes
• OpenAPI spec: Yes

What I like

It feels built for builders. Relationship data plus monitoring is a real differentiator. Most vendors stop at returning a record. NinjaPear gets closer to answering why the account matters now.

What will annoy you

If all you need is basic email append, this is more product than you need. Also, the subscription commitment is explicit and real.

Best for

Teams that care about company intelligence, timing, and AI-assisted implementation.

User signal

Public market discussion around GTM tools keeps drifting toward workflow fit, not just data size. That matches why NinjaPear ranks first here: it behaves more like a system input than a list vendor.

Star rating summary

Freshness ⭐⭐⭐⭐⭐ (5/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐⭐⭐ (5/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐⭐⭐⭐⭐ (5/5)

2. EnrichmentAPI

What it does

EnrichmentAPI is a generic enrichment API for person, company, employees, tech stack, and reverse email lookups.

How I scored it

I scored freshness 4/5 because the vendor positions the product as live enrichment and the docs discuss request retries and timeout behavior, which is at least evidence of request-time processing rather than only serving warehouse snapshots. I scored dev-friendliness 4/5 because the docs expose credit costs and ugly operational details. I held stability to 3/5 because docs explicitly mention 408s on ~1-2% of requests, which is honest but still an integration burden. AI readiness is 1/5 because I found no public evidence of agent-specific documentation assets.

Pricing

Starts at $99. Person API 5 credits, Company API 5, Employees API 10, Company Investment 1, Tech Stack 1.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

The docs disclose operational tradeoffs more clearly than most vendors do.

What will annoy you

Docs say requests may retry for up to 60 seconds, and 408s happen on roughly 1-2% of requests. So you need to engineer for that.

Best for

People who want a generic enrichment API with visible pricing and visible docs.

User signal

The strongest thing I can say here is that EnrichmentAPI is candid in docs where many competitors are vague. That matters. It reduces surprises.

Star rating summary

Freshness ⭐⭐⭐⭐☆ (4/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

3. People Data Labs

What it does

People Data Labs is builder infrastructure. Breadth. Scale. APIs designed for teams that will actually integrate and reprocess data.

How I scored it

I scored scalability 5/5 because the pricing docs, bulk API logic, and product structure clearly support larger-volume workflows. I scored freshness 3/5 because the company side still feels dataset-first, and PDL’s own ecosystem includes scheduled refresh cadences rather than a stronger live-change story. Dev-friendliness is 5/5 because the pricing docs are unusually explicit, credits are easy to model, and the API product feels like infra. AI readiness is 2/5 because the docs are strong for humans, but I found no public llms.txt, agent skill, or equivalent machine-first AI layer.

Pricing

Public pricing shows person enrichment from $98/mo for 350 credits and company enrichment from $100/mo for 1,000 credits. Docs explain credit logic clearly: successful matches generally consume 1 credit.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Good API posture. Good pricing clarity. Serious infrastructure feel.

What will annoy you

Freshness tradeoff. This feels more like a dataset company with APIs than a live-change product.

You should also be honest about sourcing risk. PDL has long been associated with LinkedIn data in the market conversation. If your legal team cares, read this: Is scraping LinkedIn legal in 2026?

Best for

Builders who want scale and broad coverage more than live-change intelligence.

User signal

The market keeps using PDL as the serious builder benchmark. That reputation is deserved on infra and API design. It is less strong on freshness.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐⭐ (5/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐⭐⭐ (5/5) | Stability ⭐⭐⭐⭐⭐ (5/5) | AI ⭐⭐☆☆☆ (2/5)

4. Apollo

What it does

Apollo is the default all-in-one outbound tool. Prospecting database, sequences, enrichment, the whole thing.

How I scored it

I scored richness 4/5 because Apollo covers person, company, and contact data well enough for a broad outbound workflow. I scored dev-friendliness 2/5 because the API starts clean but gets more complex once you use waterfall enrichment. Public docs explicitly state that when waterfall parameters are used, Apollo returns synchronous demographic and firmographic data first, then delivers email and phone enrichment asynchronously to a configured webhook. That is real complexity. Pricing is 3/5 because seats are public but serious API usage moves into custom territory.

Pricing

Basic $49, Professional $79, Organization $119 per seat monthly, billed annually. API for advanced use cases is on Custom plans.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

It works well enough to stay on a lot of shortlists.

What will annoy you

API ergonomics get more complex when you move past the happy path. Waterfall email and phone enrichment can come back asynchronously via webhook, and Apollo may retry webhook calls, so your endpoint needs idempotency.

That is a fair description of Apollo.

Best for

Teams that want convenience first.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

5. Clearbit

What it does

Clearbit is still relevant for company enrichment and routing workflows, especially in HubSpot-heavy stacks.

How I scored it

I scored freshness 4/5 because Clearbit still has a strong reputation in routing and form enrichment workflows where fast company resolution matters. I scored pricing 2/5 because public API economics are no longer easy to evaluate. I scored stability 5/5 because despite the buying-motion frustration, the product has years of operational credibility in this category.

Pricing

Opaque.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Good operating history in company enrichment and routing.

What will annoy you

The buying motion. Hidden pricing. Less self-serve. More platform gravity.

Best for

HubSpot-heavy teams doing routing and standard firmographics.

User signal

Clearbit still shows up constantly in buyer shortlists. The issue is not relevance. It is evaluation friction.

Star rating summary

Freshness ⭐⭐⭐⭐☆ (4/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐⭐ (5/5) | AI ⭐☆☆☆☆ (1/5)

6. ZoomInfo

What it does

ZoomInfo is the big enterprise incumbent. Huge dataset. Strong contact story. Enterprise buying motion.

How I scored it

I scored richness and scalability 5/5 because ZoomInfo’s entire value proposition is breadth and enterprise coverage. I scored pricing 1/5 because the API economics are opaque. I scored dev-friendliness 2/5 because enterprise vendors can have capable APIs, but public evaluation is weak and self-serve technical due diligence is harder than it should be. AI readiness stays 1/5 because I found no clear public evidence of an agent-native docs layer.

Pricing

Opaque.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Coverage, especially for enterprise US sales teams.

What will annoy you

Price opacity. Procurement drag. Contract gravity.

Best for

Large companies that want the incumbent and can pay for it.

User signal

ZoomInfo is still the enterprise default in many orgs. That says a lot about market reach. It says less about ease of evaluation.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐⭐⭐ (5/5) | Scalability ⭐⭐⭐⭐⭐ (5/5) | Pricing ⭐☆☆☆☆ (1/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐⭐⭐ (5/5) | AI ⭐☆☆☆☆ (1/5)

7. FullContact

What it does

FullContact is better thought of as identity resolution infrastructure than a straight SDR enrichment tool.

How I scored it

I scored richness 4/5 because identity stitching can be very valuable in the right stack. I scored pricing 2/5 because public evaluation is still weak. Dev-friendliness is 4/5 because the product is more infrastructure-oriented than many sales-database vendors. AI readiness is 2/5 because while the product category maps well to programmatic use, I found no public evidence of dedicated AI-doc assets.

Pricing

Mostly custom.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

It solves a real identity problem that most prospecting tools don’t.

What will annoy you

If you want a simple contact-data vendor, this is not the cleanest buy.

Best for

Identity stitching and multi-identifier systems.

User signal

FullContact makes more sense to data teams than SDR teams. That is why it ranks mid-pack instead of near the top.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐⭐☆☆☆ (2/5)

8. Hunter

What it does

Hunter is email-first. Finder. Verifier. Domain search. Some enrichment.

How I scored it

I scored pricing and dev-friendliness 4/5 because the public pricing and API credit model are clean. Hunter’s own help docs spell out API credit costs, including 0.5 credit for Email Verifier in one help center article. I scored richness 2/5 because Hunter is narrower than company-intelligence vendors. Stability is 5/5 because it has stayed focused on the problem it actually solves.

Pricing

Starter $49 monthly or $34 annual equivalent, Growth $149 or $104, Scale $299 or $209. Search and verification credits are clearly described publicly.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

It knows what it is.

What will annoy you

It is not broad company intelligence.

Best for

Email-heavy workflows.

User signal

Hunter keeps winning because teams understand what they are buying. That is underrated.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐⭐⭐ (5/5) | AI ⭐☆☆☆☆ (1/5)

9. Clay

What it does

Clay is orchestration. It is not one enrichment API. It is a way to glue several together.

How I scored it

I scored richness and dev-friendliness 4/5 because Clay gives technical teams a lot of workflow flexibility. I scored pricing 2/5 because the true cost depends on both Clay and the providers you connect. That is the core tradeoff. AI readiness is 2/5 because Clay is conceptually very useful in AI-assisted workflows, but I did not find the same kind of public machine-readable AI-doc surface as NinjaPear.

Pricing

Depends on workflow credits and provider spend.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Very flexible. Good for waterfalls, branching, and ops workflows.

What will annoy you

Budget leakage if you do not watch it carefully.

That is the right mentality with Clay. Pilot first. Model cost carefully.

Best for

GTM engineers who need orchestration.

Star rating summary

Freshness ⭐⭐⭐⭐☆ (4/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐⭐☆☆☆ (2/5)

10. Crunchbase

What it does

Crunchbase is company and funding data. Useful, but not broad contact enrichment.

How I scored it

I scored richness 3/5 because the company and funding layer is useful, but narrower than broader intelligence products. I scored dev-friendliness 4/5 because the API story is real and the company-data use cases are clear. AI readiness stays 1/5 because I found no clear public AI-doc evidence.

Pricing

Mixed.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Funding and company metadata remain useful for segmentation and market mapping.

What will annoy you

Weak person and contact story.

Best for

Company-level enrichment and funding-aware workflows.

User signal

Crunchbase still matters when the company object matters more than the contact object.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐⭐⭐ (5/5) | AI ⭐☆☆☆☆ (1/5)

11. Cognism

What it does

Cognism is premium B2B sales data, especially where phone data matters.

How I scored it

I scored richness 4/5 because the phone and contact angle is a real strength. Pricing is 2/5 because even though public CRM enrichment content references pricing from ~$12,000 annually, the actual motion is still contract-led. Dev-friendliness is 2/5 because it does not feel like a builder-first product in public.

Pricing

Public CRM enrichment content says pricing starts around $12,000 annually including 25,000 credits.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Phone coverage is stronger than a lot of mid-market vendors.

What will annoy you

Not a builder-first feel.

Best for

Teams where phone coverage matters a lot.

User signal

Cognism usually enters the conversation when teams care about higher-end sales data rather than cheap API experimentation.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐⭐☆ (4/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

12. RocketReach

What it does

RocketReach is contact-finding API territory. Email. Phone. Straight-line use cases.

How I scored it

I scored richness 3/5 because the contact layer is useful but not especially broad. I scored pricing 3/5 because the public site exposes plans and mentions API limits, but the real API economics still drift into contract language. Stability is 4/5 because it is a familiar product with a long operating history.

Pricing

Public pricing shows plans with higher API limits starting around $6k annually, but API-only economics are still not especially crisp.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Familiar and usually serviceable.

What will annoy you

It rarely wins on workflow depth or pricing clarity.

Best for

Basic contact enrichment.

User signal

RocketReach is often the answer when teams want something known and adequate, not especially opinionated.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

13. UpLead

What it does

UpLead gives you verified contacts and company data in a cleaner mid-market package.

How I scored it

I scored most dimensions at 3/5 because UpLead is competent across the board without being especially differentiated. Stability gets 4/5 because it remains a credible mid-market option. AI readiness stays 1/5 because I found no clear public evidence beyond standard docs.

Pricing

Public plans exist and the site says API access is included by plan. Real economics still depend on plan level.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Less enterprise theater than ZoomInfo.

What will annoy you

Still feels more sales tool than developer platform.

Best for

Mid-market teams that want verified contacts without ZoomInfo pricing gravity.

User signal

UpLead tends to come up when buyers want something cleaner than the enterprise incumbents and less ops-heavy than Clay.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

14. Dropcontact

What it does

Dropcontact is email enrichment with pay-for-success pricing and privacy positioning.

How I scored it

I scored pricing 4/5 because the public pay-on-success model is straightforward and rational. I scored richness 2/5 because this is a narrower email enrichment product, not a broader account-intelligence layer. Stability is 4/5 because the product knows its lane.

Pricing

You pay when an email is found or verified.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Paying for success is rational.

What will annoy you

Scope is narrow.

Best for

Privacy-conscious email enrichment.

User signal

Dropcontact is appealing when buyers are tired of paying for misses.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

15. Clearout

What it does

Clearout is email finder, verifier, and narrow enrichment.

How I scored it

I scored pricing 4/5 because public pricing is easy to find and the rollover policy is unusually buyer-friendly. I scored richness 2/5 because it is still a narrow product relative to broader enrichment APIs. Stability is 4/5 because the economics are transparent and the scope is clear.

Pricing

Starter 3,000 credits at $16/mo annual or $19.5 monthly. Pro 10K credits at $32/mo annual or $40 monthly. Credits roll over.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Clear economics.

What will annoy you

Narrower scope than people think.

Best for

Verifier-heavy email workflows.

User signal

Clearout is one of the easier products here to reason about financially. That matters more than people admit.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

16. Snov.io

What it does

Budget outbound platform with enrichment features.

How I scored it

I scored pricing 4/5 because public entry pricing is easy to find and low enough for small teams to test. I scored dev-friendliness 2/5 because while API access exists, the product still feels like an outbound suite first and infra second. AI readiness stays 1/5 because I found no public evidence of agent-specific docs.

Pricing

Around $39/mo publicly.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Cheap to try.

What will annoy you

Not serious data infrastructure.

Best for

Small outbound teams with small budgets.

User signal

Snov.io tends to win small-budget experiments, not serious platform decisions.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

17. Lusha

What it does

Lusha is contact data for SDR teams.

How I scored it

I scored richness 3/5 because the contact layer is useful for rep workflows. I scored pricing and dev-friendliness 2/5 because the API is not the center of gravity and the product story is more sales-tool than developer platform.

Pricing

Public plans exist. API is not the center of gravity.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Simple SDR product story.

What will annoy you

Not very interesting for flexible product workflows.

Best for

SDR teams that want speed over elegance.

User signal

Lusha is easy to explain internally. That is a real buying advantage, even if it is not the most flexible API product.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

18. ContactOut

What it does

ContactOut is people-first enrichment with recruiter DNA.

How I scored it

I scored richness 2/5 because the company story is weak, but the people and contact use case is clear. Pricing and dev-friendliness sit at 3/5 because public pricing exists and API access exists, but the platform is still more recruiter/contact oriented than broad enrichment infra.

Pricing

$99/mo for email. $199/mo for email + phone.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Useful if your problem is people and contact info.

What will annoy you

Weak company story.

Best for

Recruiting and sourcing.

User signal

ContactOut makes more sense when the person object matters more than the account object.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

19. LeadMagic

What it does

LeadMagic is API-first enough to be interesting if you think in waterfalls.

How I scored it

I scored pricing and dev-friendliness 4/5 because the pay-per-result framing and API orientation make it easier to reason about than many sales-led tools. I scored AI readiness 2/5 because there is at least some public AI-agent positioning, but not the stronger machine-readable evidence I looked for elsewhere. Stability is 3/5 because the brand is still less proven than larger incumbents.

Pricing

Starts at $49/mo with pay-per-result positioning.

AI dimension

• AI Skill: Some public AI-agent positioning
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Interesting alternative to bigger incumbents if you care about waterfall economics.

What will annoy you

Brand trust is lower.

Best for

Waterfall-heavy GTM engineering.

User signal

LeadMagic is the sort of vendor technical buyers try when they are tired of paying for broad seats they do not need.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐⭐☆☆☆ (2/5)

20. Kaspr

What it does

Kaspr is LinkedIn-URL-driven contact enrichment.

How I scored it

I scored richness 2/5 because it is useful but narrow. Pricing and scalability are 3/5 because public plans exist and API access starts at Starter, but it is still not the primary product story. Dev-friendliness is 2/5 because the API feels secondary.

Pricing

Starts at €45/mo. API from Starter.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Simple fit if LinkedIn URL is your starting key.

What will annoy you

Credit logic can get annoying. Export credits apply too.

Best for

Known-profile enrichment.

User signal

Kaspr is practical when your workflow already starts from known profiles, less compelling as a general data layer.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

21. Prospeo

What it does

Prospeo is a lean, cheaper enrichment option for emails, phones, and simple lookups.

How I scored it

I scored pricing 4/5 because the public credit model is simple. Richness is 2/5 because breadth is limited. Dev-friendliness and stability sit at 3/5 because the product is transparent but clearly aimed at smaller workflows.

Pricing

Public API pricing says 1 credit per enrichment request.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Transparent. Cheap enough.

What will annoy you

Limited breadth.

Best for

Small teams optimizing for cost.

User signal

Prospeo makes the most sense when cost discipline matters more than breadth.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

22. Adapt.io

What it does

Adapt.io is an older B2B lead platform that still shows up in evaluations.

How I scored it

I scored most dimensions between 2/5 and 3/5 because it is serviceable, public enough to understand, and less differentiated than more active products in the category. AI readiness stays 1/5 because I found no clear public evidence of agent-oriented docs.

Pricing

Free, $49, and $99 public tiers.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Easy enough to understand.

What will annoy you

This is not where the category feels active.

Best for

Teams that already know the tool.

User signal

Adapt is still in evaluation sets mostly because it has been around for a while, not because the category feels centered there.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

23. Seamless.AI

What it does

Seamless.AI is a high-awareness outbound data vendor.

How I scored it

I scored awareness-driven richness 3/5 because the outbound use case is obvious, but pricing, dev-friendliness, and stability all land lower because public API evaluation remains fuzzy and buyer skepticism is part of the market conversation. AI readiness is 1/5 because I found no clear public evidence.

Pricing

Free trial. Real pricing gets sales-led.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Awareness matters. Some teams buy the known brand.

What will annoy you

Trust issues and vague pricing.

Best for

Teams that want awareness and broad outbound utility.

User signal

This is one of the vendors where brand visibility outruns product trust in a lot of buyer conversations.

Star rating summary

Freshness ⭐⭐☆☆☆ (2/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐☆☆☆ (2/5) | Dev ⭐⭐☆☆☆ (2/5) | Stability ⭐⭐☆☆☆ (2/5) | AI ⭐☆☆☆☆ (1/5)

24. Datagma

What it does

Datagma is a lower-visibility API-first-ish alternative.

How I scored it

I scored pricing 4/5 because public entry pricing is visible. Richness is 2/5 because the proof footprint is smaller and the product looks narrower than higher-ranked vendors. Dev-friendliness and stability sit at 3/5 because it is testable without too much friction.

Pricing

Starts at $39/mo billed yearly.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Cheap enough to test. Worth a look if you want alternatives.

What will annoy you

Smaller proof footprint.

Best for

Buyers who want a lower-cost API-first option.

User signal

Datagma is the kind of vendor technical buyers try when they want to get outside the loud incumbent set.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐☆☆☆ (2/5) | Scalability ⭐⭐⭐☆☆ (3/5) | Pricing ⭐⭐⭐⭐☆ (4/5) | Dev ⭐⭐⭐☆☆ (3/5) | Stability ⭐⭐⭐☆☆ (3/5) | AI ⭐☆☆☆☆ (1/5)

25. Coresignal

What it does

Coresignal is closer to workforce and public-web data infrastructure than a clean general enrichment buy.

How I scored it

I scored scalability 4/5 because the API-plus-dataset model works for technical teams building data products. I scored richness 3/5 because workforce and company-web data can be useful, but this is not the cleanest general enrichment fit. Pricing is 3/5 because public API entry pricing starts at $49/mo, but dataset economics can expand quickly. AI readiness is 1/5 because I found no clear public machine-first AI docs layer.

Pricing

API starts at $49/mo. Datasets cost more.

AI dimension

• AI Skill: No clear public evidence found
• MCP or agent path: No clear public evidence found
• Markdown docs: No clear public evidence found
• llms.txt: No clear public evidence found
• OpenAPI spec: No clear public evidence found

What I like

Useful if you care about workforce or company data layers.

What will annoy you

It is not the cleanest plug-and-play enrichment product.

Like PDL, it also lives near the LinkedIn-derived data conversation. If that matters to your counsel, read this: Is scraping LinkedIn legal in 2026?

Best for

Workforce intelligence and custom data products.

User signal

Coresignal makes the most sense when enrichment is one layer inside a larger data workflow, not the whole buying reason.

Star rating summary

Freshness ⭐⭐⭐☆☆ (3/5) | Richness ⭐⭐⭐☆☆ (3/5) | Scalability ⭐⭐⭐⭐☆ (4/5) | Pricing ⭐⭐⭐☆☆ (3/5) | Dev ⭐⭐⭐⭐☆ (4/5) | Stability ⭐⭐⭐⭐☆ (4/5) | AI ⭐☆☆☆☆ (1/5)

What most buyers miss

Freshness beats field count

Twenty wrong fields are worse than five right ones.

A bigger field list does not help if the org changed, the exec left, or the company pivoted.

Credits hide real cost

Most pricing spreadsheets are wrong because they model one pass.

Real cost is:

• initial enrichment
• misses
• premium fields
• re-enrichment
• waterfall fallback
• webhook and ops overhead

That is how a cheap API becomes an expensive one.

Workflow fit matters more

A wrong field is worse than a blank field.

Blank fields make your system cautious. Wrong fields make your reps overconfident.

That thread was about tooling replacement, but the point is broader. Use-case mismatch breaks tools quickly.

AI-readiness is now real

This is not a side issue anymore.

If your docs are hard for AI coding agents to consume, implementation gets slower and more brittle. Teams feel that immediately.

My hot takes

• Freshness is the product. Old data with more fields is still old data.
• Opaque pricing is a product flaw. If I need a sales call to find out whether a tool is in budget, evaluation got harder for no good reason.
• Most all-in-one enrichment tools are really prospecting databases with an API attached. That changes how you should buy them.
• A wrong field is worse than a blank field. Blank makes software cautious. Wrong creates bad decisions.
• AI-readiness is not optional anymore. If Claude or Cursor cannot consume your docs, your developer experience is behind.
• Static enrichment is the start. The next question is what changed and why now.

Final picks by use case

If you want the short version:

Best overall data enrichment api

NinjaPear

Because it is pointed at modern workflows: company intelligence, relationship mapping, monitoring, and AI-friendly docs.

Best exact-match generic enrichment API

EnrichmentAPI

Because it is focused, public, and easy to reason about.

Best builder-grade data layer

People Data Labs

Because it still feels like serious infrastructure, assuming you understand the freshness tradeoff and the LinkedIn data conversation.

Best default prospecting stack with enrichment included

Apollo

Because it is still the broad convenience play, even if the API side gets more complex.

Best for HubSpot-heavy routing workflows

Clearbit

If you can tolerate opaque pricing.

Best for email-centric enrichment

Hunter

Simple. Focused. Usually enough.

Best for waterfall orchestration

Clay if you need orchestration.

LeadMagic if you want something more API-centered.

Best for enterprise incumbency

ZoomInfo

If you have budget and patience.

The actual advice is simple: stop asking which data enrichment api has the most fields. Ask which one fits your workflow, refresh cadence, and tolerance for pricing games.

If your real problem is timing, org change, competitor movement, or relationship mapping, generic enrichment is not enough. Start with NinjaPear.

If your problem is simpler, test EnrichmentAPI and People Data Labs next.

And if you want to check your own cost model before you buy anything, use the calculator below. It will save you more money than another vendor call.

TL;DR

This is the full market map. Average score is the sum of the 7 category scores divided by 7.

That is the board.

If you want the most interesting thing to evaluate first, start with NinjaPear.

If you want a cleaner generic enrichment product, test EnrichmentAPI.

If you want serious builder infrastructure, test People Data Labs.

If you want convenience and can live with some complexity, Apollo is still there.

If you searched for Crunchbase API, the main thing to understand is simple: Crunchbase Basic is not the full Crunchbase API. Basic gives you 3 endpoints. Full API access requires an Enterprise or Applications license. I also included a public GitHub repo in this guide so you can clone the sample scripts and start testing right away.

That quote is the whole story in one sentence. People think they bought data access. What they often bought was a much smaller surface area.

What Crunchbase API actually is

Crunchbase’s public API is a read-only REST API. You ask for records. You get JSON back. There is no mystery there.

The public API has three core motions:

1. Autocomplete: you have a fuzzy company name and need a canonical match.
2. Entity lookup: you know the company and want its record.
3. Search: you want a filtered list of companies.

Then there is a richer layer on top of that: related cards and broader entity families in full API access.

If you are building against Crunchbase, most flows look like this:

• resolve a name with Autocomplete
• fetch the company with Organization Entity Lookup
• optionally add related cards like funding rounds, investors, or acquisitions
• repeat at scale with Search

That is the product, in practical terms.

How access actually works

This part makes more sense once you know the API surface.

Crunchbase Basic

Crunchbase support docs say Basic users can provision an API key.

That is true. It is also easy to overread.

Basic does not mean full API access. It means access to exactly three endpoints:

1. Organization Search
2. Organization Entity Lookup
3. Autocomplete

That is enough to test the core workflow.

It is not the same thing as full Crunchbase API access.

Full API access

Crunchbase says this directly on the Using the API page:

“Access to the Full API Requires an Enterprise or Applications License.”

That is the line that matters.

If you need broader access than Basic, you are in a licensing motion. Not a normal self-serve checkout motion.

The $99 question

From the public docs in this guide, I cannot say that a $99 Crunchbase plan gives you full API access.

The docs point the other way. Full API access requires Enterprise or Applications licensing.

So if your internal question is:

“Can I pay for a normal Crunchbase plan and get the full API?”

The answer from the public evidence here is: do not assume that.

Different complaint, same pattern. The disappointment often comes from misunderstanding the boundary.

Auth is simple

To be fair, authentication is not the hard part.

curl 'https://api.crunchbase.com/api/v4/entities/organizations/crunchbase' \
  -H 'X-cb-user-key: YOUR_KEY'

You can pass the API key as:

• user_key in the URL
• X-cb-user-key in the header

That part is clean.

Reverse engineering Crunchbase’s internal GraphQL and dashboard API

Short warning: using Crunchbase’s internal dashboard requests instead of the sanctioned API can breach Crunchbase’s terms of service.

Now the useful part.

There are public signs that people do exactly this when they want exports or broader access without proper API licensing:

• Apify actors that ask for a logged-in Crunchbase search URL plus browser cookies
• scraper repos that automate Crunchbase search pages and organization pages
• vendors selling Crunchbase scraping APIs instead of telling you to use the official REST API

That tells you what the real playbook looks like.

The common techniques are usually:

1. replay internal authenticated requests from a logged-in browser session
2. drive a logged-in browser and extract rendered rows or JSON payloads

The first is cleaner when it works.

How people find the internal requests

The usual workflow is straightforward:

1. Log in to Crunchbase in Chrome.
2. Open DevTools.
3. Go to the Network tab.
4. Filter by fetch or XHR.
5. Open a Crunchbase search page or company page.
6. Look for requests with JSON payloads, GraphQL-style operationName fields, or large filter objects.
7. Right-click the interesting request and copy it as cURL or HAR.

In practice, the requests you see tend to look like one of these:

• POST to a GraphQL endpoint with operationName, variables, and maybe extensions
• POST to an internal search endpoint with filters and selected fields in JSON
• GET with a large encoded filter blob in the query string

The exact path can change. That is one reason these flows are fragile.

What auth usually looks like

Internal requests often depend on one or more of these:

• session cookies
• CSRF or anti-forgery headers
• request headers like x-requested-with
• a bearer token in browser storage
• a persisted GraphQL query hash

The simplest path is still the practical one:

• log in normally
• copy the working request from DevTools
• replay it before the session expires

That is also why public Apify flows tell users to export cookies.

Sample script: replay a copied GraphQL request

Replace the placeholders below with the values from a real DevTools request you copied from a logged-in Crunchbase session.

import json
import requests

session = requests.Session()

headers = {
    'User-Agent': 'Mozilla/5.0',
    'Accept': 'application/json',
    'Content-Type': 'application/json',
    'Origin': 'https://www.crunchbase.com',
    'Referer': 'https://www.crunchbase.com/',
    'x-csrf-token': 'YOUR_CSRF_TOKEN',
}

cookies = {
    'session': 'YOUR_SESSION_COOKIE',
}

payload = {
    'operationName': 'YOUR_OPERATION_NAME',
    'variables': {
        'page': 1,
        'limit': 50,
        'query': 'fintech',
        'filters': []
    },
    'query': 'YOUR_REAL_QUERY_OR_HASH'
}

r = session.post(
    'https://www.crunchbase.com/graphql',
    headers=headers,
    cookies=cookies,
    data=json.dumps(payload),
    timeout=30,
)

print(r.status_code)
print(r.text[:2000])

Sometimes the endpoint is not literally /graphql. Sometimes the request uses extensions.persistedQuery instead of a raw query string. That is why the right starting point is Copy as cURL, not guessing.

Sample script: start from Copy as cURL

This is usually the fastest route.

1. Right-click the working request in DevTools.
2. Choose Copy as cURL.
3. Paste it somewhere safe.
4. Convert it to Python manually or with a converter.

Skeleton:

import requests

url = 'https://www.crunchbase.com/YOUR_REAL_INTERNAL_ENDPOINT'

headers = {
    'accept': 'application/json',
    'content-type': 'application/json',
    'origin': 'https://www.crunchbase.com',
    'referer': 'https://www.crunchbase.com/discover/organization.companies',
    'user-agent': 'Mozilla/5.0',
    'x-csrf-token': 'PASTE_FROM_CURL',
}

cookies = {
    'PASTE_COOKIE_NAME': 'PASTE_COOKIE_VALUE',
}

payload = {
    # paste the real JSON body from the copied request
}

r = requests.post(url, headers=headers, cookies=cookies, json=payload, timeout=30)
print(r.status_code)
print(r.json())

A copied request usually gives you:

• the real URL
• the real headers
• the real cookies
• the real payload shape

That is most of the work.

Sample script: paginate search exports

Once you have one working internal search request, paginating it is usually straightforward because the payload often carries page or offset controls.

import requests
import time

session = requests.Session()

headers = {
    'accept': 'application/json',
    'content-type': 'application/json',
    'origin': 'https://www.crunchbase.com',
    'referer': 'https://www.crunchbase.com/discover/organization.companies',
    'user-agent': 'Mozilla/5.0',
    'x-csrf-token': 'YOUR_CSRF_TOKEN',
}

cookies = {
    'session': 'YOUR_SESSION_COOKIE',
}

base_url = 'https://www.crunchbase.com/YOUR_REAL_INTERNAL_SEARCH_ENDPOINT'
results = []

for page in range(1, 6):
    payload = {
        'operationName': 'YOUR_OPERATION_NAME',
        'variables': {
            'page': page,
            'limit': 50,
            'filters': [],
            'field_ids': ['identifier', 'short_description']
        },
        'query': 'YOUR_REAL_QUERY_OR_HASH'
    }

    r = session.post(base_url, headers=headers, cookies=cookies, json=payload, timeout=30)
    r.raise_for_status()
    data = r.json()
    results.append(data)
    print(f'fetched page {page}')
    time.sleep(2)

print(f'total pages fetched: {len(results)}')

The key idea is simple: copy a working request, then vary only the paging variables.

Sample script: browser automation fallback

If replaying internal requests gets blocked, the common fallback is browser automation on a logged-in session.

That is why public Crunchbase scraping repos often lean on Selenium or remote browsers.

Minimal shape:

from selenium import webdriver
from selenium.webdriver.common.by import By
import time

driver = webdriver.Chrome()
driver.get('https://www.crunchbase.com/login')

print('Log in manually, then press Enter here...')
input()

search_url = 'https://www.crunchbase.com/discover/organization.companies'
driver.get(search_url)
time.sleep(5)

rows = driver.find_elements(By.CSS_SELECTOR, 'grid-row, [role="row"]')
print(f'rows found: {len(rows)}')

for row in rows[:5]:
    print(row.text)

driver.quit()

This is heavier than replaying JSON, but sometimes it is the faster way through a changing frontend.

What usually breaks

The usual failure modes are predictable:

• session cookies expire
• CSRF token rotates
• persisted query hash changes
• GraphQL schema or field names change
• anti-bot checks kick in
• the table UI changes

This is why these workarounds tend to turn into maintenance projects.

Endpoint breakdown

Autocomplete

Endpoint: GET /api/v4/autocompletes

Use this when your input is messy. A user types open ai. A CRM field says stripe inc. You need the canonical entity.

What it gives you:

• suggested matches
• canonical identifiers
• permalinks to feed into lookup calls

Example:

curl 'https://api.crunchbase.com/api/v4/autocompletes?query=stripe' \
  -H 'X-cb-user-key: YOUR_KEY'

This is a helper endpoint. It is not where the interesting data lives. It is what keeps the rest of your pipeline from being garbage.

Organization Entity Lookup

Endpoint: GET /api/v4/entities/organizations/{permalink}

This is the workhorse.

Once you have a valid permalink, this endpoint returns the core organization record. Public docs and examples show fields around:

• identifier
• permalink
• uuid
• short_description
• website
• category references
• location references
• founded_on
• rank fields like rank_org_company

Trimmed sample response shape based on Crunchbase docs/examples:

{
  "properties": {
    "identifier": {
      "value": "Crunchbase",
      "permalink": "crunchbase",
      "entity_def_id": "organization"
    },
    "short_description": "Crunchbase is a prospecting platform...",
    "rank_org_company": 1234
  }
}

Example:

curl 'https://api.crunchbase.com/api/v4/entities/organizations/crunchbase' \
  -H 'X-cb-user-key: YOUR_KEY'

This is the endpoint you use for:

• CRM enrichment
• internal company profiles
• pre-call research
• startup research
• grounding any workflow in a known company record

Organization Search

Endpoint: POST /api/v4/searches/organizations

This is the list builder.

Use it when you do not know the exact company yet and need a filtered set of organizations.

Crunchbase docs show support for JSON request bodies with things like:

• field_ids
• query
• category filters
• location filters
• funding filters
• employee range enums like num_employees_enum

The docs also say:

• default page size: 50
• max page size: 1000

That matters if you are bulk-enriching or backfilling data.

Example:

import requests

r = requests.post(
  'https://api.crunchbase.com/api/v4/searches/organizations',
  headers={'X-cb-user-key': 'YOUR_KEY'},
  json={
    'field_ids': ['identifier', 'short_description']
  }
)
print(r.json())

Trimmed sample response shape based on docs/examples:

{
  "entities": [
    {
      "identifier": {
        "value": "Stripe",
        "permalink": "stripe"
      },
      "short_description": "Stripe is a financial infrastructure platform."
    },
    {
      "identifier": {
        "value": "Adyen",
        "permalink": "adyen"
      },
      "short_description": "Adyen is a payments technology company."
    }
  ]
}

This is what you use for:

• prospect list seeding
• startup discovery
• market mapping
• filtered company exports into your own workflows

Related cards

This is where Crunchbase gets more interesting.

Once you have an organization, you can request related cards for richer data. Public examples and docs reference cards around:

• raised funding rounds
• investor participation
• acquisitions
• founder or leadership context

Example:

curl 'https://api.crunchbase.com/api/v4/entities/organizations/openai?card_ids=raised_funding_rounds' \
  -H 'X-cb-user-key: YOUR_KEY'

Trimmed sample response shape:

{
  "cards": {
    "raised_funding_rounds": [
      {
        "identifier": {"value": "Series C"},
        "announced_on": "2023-01-01",
        "money_raised": {"value_usd": 1000000000}
      }
    ]
  }
}

This is the layer that makes Crunchbase useful for investor research and private-market history, not just company pages.

What Crunchbase Basic actually gives you

Crunchbase’s Basic API docs are very clear here.

Basic gives you exactly 3 endpoints:

1. Organization Search
2. Organization Entity Lookup
3. Autocomplete

That is enough to test the core workflow.

It is not the same thing as full Crunchbase API access.

That distinction is the first thing I would tell any engineer before they write a single line of integration code.

What data you can realistically pull

This is the endpoint view translated into data jobs.

Company identity

Mostly from:

• Autocomplete
• Organization Entity Lookup

Useful fields include:

• company name
• permalink
• UUID
• website or domain
• short description
• rank fields

This is your anchor layer.

Firmographic context

Mostly from:

• Organization Entity Lookup
• Organization Search

Useful fields and filters include:

• location
• categories
• founded date
• employee range enums
• company profile context
• funding-related search filters

This is where Crunchbase works well for segmentation and basic enrichment.

Funding and investors

Mostly from:

• Organization Entity Lookup with cards
• broader full-API entity relationships when licensed

Useful data includes:

• funding rounds
• announced dates
• amount raised
• investor relationships
• acquisitions context
• private-market history

This is still the main reason to buy Crunchbase.

People and leadership context

Mostly from:

• people-related cards and fuller licensed access

This gives you founder and executive context.

It is useful. It is also not the same thing as GTM-ready people enrichment or contactability.

Discovery support

Mostly from:

• Organization Search
• Autocomplete

Use these when your question is not “tell me about company X” but “show me companies that fit this shape.”

Crunchbase API pricing

This section is short because public pricing information is short.

What is public

From public docs and support pages, we can verify:

• Basic access exists
• Basic users can provision an API key
• full API requires Enterprise or Applications licensing
• documented rate limit is 200 calls/minute
• API customers get live company data at scale with unlimited exports
• Business plan customers get 5K data exports per month

That tells you Crunchbase treats API customers and UI customers as different commercial tracks.

What is not public

There is no clean public self-serve full API price in the material here.

So if you need full API breadth, the public path points you toward a licensing conversation.

That matters because it changes how engineers test and how teams budget.

Why this matters by buyer type

Founder or builder: this slows cheap experimentation.

RevOps team: this makes budgeting messy.

Enterprise buyer: this is less unusual.

Customer-facing product team: rights matter as much as price.

Most teams think they are buying rows. They are actually buying permission.

PAYG contrast

This is where NinjaPear Pricing is easier to reason about.

Publicly visible right now:

• 3-day free trial
• 10 credits included
• PAYG credits valid for 18 months
• Customer Listing pricing of 1 credit/request + 2 credits/customer returned

On public product pages, NinjaPear also shows:

• Company Details: 2 credits per call
• Employee Count: 2 credits per call
• Company Updates: 2 credits per call
• Company Funding: 2+ credits per call

If you want to run real calls before talking to anyone, that difference matters.

Use case: CRM enrichment

The problem

Your CRM has company names and maybe domains. Reps need enough context to stop guessing.

The minimum viable Crunchbase chain is:

• Autocomplete
• Organization Entity Lookup
• optional funding card if licensed

That gives you identity plus a usable company profile.

Short code snippet

import requests

r = requests.get(
  'https://api.crunchbase.com/api/v4/entities/organizations/stripe',
  headers={'X-cb-user-key': 'YOUR_KEY'}
)
print(r.json())

Sample response

Trimmed sample response shape based on docs/examples:

{
  "properties": {
    "identifier": {
      "value": "Stripe",
      "permalink": "stripe"
    },
    "short_description": "Stripe is a financial infrastructure platform.",
    "website": {"value": "https://stripe.com"},
    "founded_on": {"value": "2010-01-01"}
  }
}

Where it falls short

This is static enrichment. It does not tell you:

• what changed this week
• who buys from them
• who they compete with
• whether sales should care right now

Closest NinjaPear alternative

For this workflow, the closest NinjaPear mapping is:

• Company Details
• Employee Count
• Company Updates if freshness matters
• NinjaPear for Claude if your team wants enrichment inside AI workflows

Use case: prospect list building

The problem

You want a list of companies that match a thesis. Not a bag of random logos.

The Crunchbase chain is:

• Organization Search
• Organization Entity Lookup
• optional people or funding cards if licensed

Use Search to get the candidate set. Use Entity Lookup to flesh out the winners.

Short code snippet

import requests

r = requests.post(
  'https://api.crunchbase.com/api/v4/searches/organizations',
  headers={'X-cb-user-key': 'YOUR_KEY'},
  json={
    'field_ids': ['identifier', 'short_description']
  }
)
print(r.json())

Where it falls short

A prospect list is not a pipeline list.

You still need:

• timing
• fit
• relationship context
• some reason for now

Closest NinjaPear alternative

This is where Customer API and Competitor API feel more GTM-native:

• Customer API for finding who buys from a company or category player
• Competitor API for adjacency and similar-company discovery
• Company Details for enrichment after discovery

Use case: investor research

The problem

You need startup, round, investor, and acquisition context fast.

This is where Crunchbase is strongest.

The typical chain is:

• Organization Entity Lookup
• funding-related cards
• investor-related cards
• acquisition cards where relevant

Short code snippet

curl 'https://api.crunchbase.com/api/v4/entities/organizations/openai?card_ids=raised_funding_rounds' \
  -H 'X-cb-user-key: YOUR_KEY'

Sample response

Trimmed sample response shape based on docs/examples:

{
  "cards": {
    "raised_funding_rounds": [
      {
        "identifier": {"value": "Series C"},
        "announced_on": "2023-01-01",
        "money_raised": {"value_usd": 1000000000}
      }
    ]
  }
}

My take

Crunchbase wins here.

If funding data is the job, this is where it is strongest.

Where NinjaPear fits instead

Use NinjaPear when the question changes from:

• “who raised?” to
• “what changed?”
• “who are their customers?”
• “who competes with them?”
• “should sales care now?”

Closest mappings:

• Company Funding
• Company Updates
• Customer API
• Competitor API

Use case: account research

The problem

A rep has a meeting tomorrow and wants context that is useful.

The Crunchbase chain is:

• Autocomplete
• Organization Entity Lookup
• optional people or funding cards if licensed

That gives you a decent pre-call brief.

What it misses

Usually the actual trigger to act.

That might be:

• a pricing page change
• a product launch post
• expansion hiring
• customer adjacency
• competitor overlap

Closest NinjaPear alternative

Stronger fit here:

• Company Monitor
• Monitor API
• Employee API
• Customer Listing
• Competitor API

Short NinjaPear snippet

curl -G 'https://nubela.co/api/v1/customer/listing' \
  --data-urlencode 'website=https://stripe.com' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Sample response

Trimmed sample response shape based on public docs:

{
  "company": "Stripe",
  "customers": [
    {
      "company_name": "Shopify",
      "website": "shopify.com",
      "relationship_type": "customer"
    },
    {
      "company_name": "Lyft",
      "website": "lyft.com",
      "relationship_type": "customer"
    }
  ]
}

Use case: watchlists and monitoring

The problem

You do not want a static company record. You want to know when the company moves.

From the public Crunchbase materials in this guide, the API is not positioned as a blog, X, and website monitoring product.

You can build repeated search and repeated lookup flows. That is not the same thing as a first-class monitoring system.

Why this matters

For GTM, timing beats trivia.

Closest NinjaPear alternative

This is where Company Monitor is the better fit:

• Monitor API
• Company Updates
• AI-filtered changes across blog, website, and X

Short workflow snippet

Create feed in NinjaPear Monitor API -> poll RSS/API -> push meaningful changes to Slack or CRM

Sample output

<item>
  <title>Stripe: New Checkout Experience for Global Payments</title>
  <category>blog</category>
  <pubDate>Thu, 27 Feb 2026 10:00:00 GMT</pubDate>
</item>

Use case: customer-facing products

The problem

You want to put company data inside your own product.

This is where data buying turns into rights buying.

Crunchbase explicitly separates:

• Data Enrichment, for internal workflows
• Data Licensing, for customer-facing products

The catch

Before you ship anything, ask:

• can I display this data to my users?
• do I need attribution?
• do links need to be visible and spiderable?
• can I redistribute raw data?
• what happens if the contract ends?

Closest NinjaPear alternative

NinjaPear is cleaner here when the buyer wants:

• self-serve testing first
• PAYG motion
• AI-agent docs
• customer, competitor, employee, and monitoring data in one stack

Still, read the terms.

Workflow pricing cards

I am not going to make up Crunchbase numbers that are not public. So here is the honest version.

CRM enrichment

Prospect list building

Investor research

Account research

Watchlists and monitoring

Customer-facing products

A numeric NinjaPear example we can actually do

Finding customers for 100 target vendors

Known from public pricing:

• base requests: 100 x 1 credit = 100 credits
• if average returned customers = 10/company, returned records = 100 x 10 x 2 credits = 2,000 credits
• total = 2,100 credits

The 10/company value is an assumption for illustration. It is not a measured benchmark.

Rate limits and gotchas

200 calls per minute

Crunchbase docs say 200 calls per minute.

That is fine for:

• individual lookups
• modest enrichment jobs
• basic search flows

It gets more annoying for:

• large backfills
• multi-tenant apps
• workflows that fan out across cards and related entities

The real bottleneck is often not RPM

Usually it is one of these:

• access tier limits
• export restrictions
• attribution restrictions
• procurement delays

Most teams think they are buying rows. They are actually buying permission.

Attribution and licensing

This is one of the highest-value parts of the whole guide.

Internal use is the safe default

Crunchbase says:

“We encourage you to leverage the API for your internal business and research needs.”

That is the safe default.

Attribution rules matter

Crunchbase says attribution must:

• include a hyperlink to Crunchbase
• point to the entity page if the content is primarily about one entity
• be plainly visible to the end user
• be in close proximity to the data
• be visible to spiders
• not include nofollow

That is not a legal footnote. That is product behavior.

Why this becomes a product problem

Attribution affects:

• UI layout
• SEO behavior
• display logic
• distribution rights
• how native the data feels inside your app

NinjaPear alternatives by endpoint

Here is the cleanest mapping I can give without pretending the products are identical.

Notes:

• be honest when the mapping is not 1:1
• Crunchbase wins on deep private-market funding context
• NinjaPear wins when the workflow is GTM, monitoring, customer graphing, competitor mapping, or AI-native use

Who should use what

Use Crunchbase if

• you care most about funding and investors
• you do private-market research
• you are in VC, PE, corp dev, or startup strategy
• you can live with sales-led access for full API needs

Use NinjaPear if

• you need PAYG access now
• you want to test before you commit
• you care about customers, competitors, employees, and company updates
• you want to work inside Claude or AI-agent tooling

Use both if

• you genuinely need funding depth and GTM actionability
• research and sales both touch the same accounts
• one team cares about private-market graph data and another cares about timing

Crunchbase vs NinjaPear scorecard

Average score: Crunchbase 2.44/5, NinjaPear 4.11/5.

Final verdict

Use Crunchbase when funding data is the job. Use NinjaPear when GTM intelligence is the job. Use both only if you genuinely need both layers.

If I were evaluating the Crunchbase API from scratch in 2026, I would do it in this order:

1. test whether Basic’s 3 endpoints already cover the workflow
2. confirm whether the real job is funding research or GTM actionability
3. if it is funding, keep pushing on Crunchbase
4. if it is GTM, monitoring, customer graphs, competitor graphs, or AI-native workflows, test NinjaPear first because the feedback loop is shorter

And if you want the practical version, not another API explainer, clone the repo and start with the scripts. That will tell you more in an hour than most comparison pages will tell you in a week.

I'm happy to introduce a new Website Lookup Endpoint, which takes a company name and returns its website. We also know that there are companies which are similarly named, so you can further refine the search with a hint and a country to find the right company.

We believe this new API endpoint will help some of you build a canonical ID for your prospects via the company's website—the same ID that we use to identify businesses.

The Website Lookup Endpoint costs 1 credit per lookup. Based on our testing, it returns a result nearly 100% of the time (as long as the company's website exists) in 2-3s per query on average.

Executive Data in Company Details Endpoint

I am also happy to share that you can finally get Executive Officers (aka decision makers) whenever you make a Company Details API Endpoint call. This is what it looks like for Stripe:

{
  "addresses": [
    {
      "address_type": "HEADQUARTERS",
      "city": "South San Francisco",
      "country": "United States",
      "country_code": "US",
      "is_primary": true,
      "line1": "354 Oyster Point Boulevard",
      "line2": null,
      "postal_code": "94080",
      "state": "CA"
    }
  ],
  "company_type": "PRIVATELY_HELD",
  "cover_pic_url": "https://images.stripeassets.com/fzn2n1nzq965/XtX984S1GJVsVOXFC7kMu/01988281e867728dfb09aa7793a6e3b9/Stripe.jpg?q=80",
  "description": "Stripe is a financial services platform that helps businesses accept payments, build flexible billing models, and manage money movement.",
  "employee_count": 8259,
  "executives": [
    {
      "name": "Patrick Collison",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Patrick&last_name=Collison",
      "role": "CEO",
      "title": "Co-founder and CEO"
    },
    {
      "name": "John Collison",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=John&last_name=Collison",
      "role": "PRESIDENT",
      "title": "Co-founder and President"
    },
    {
      "name": "Will Gaybrick",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Will&last_name=Gaybrick",
      "role": "PRESIDENT",
      "title": "President, Technology and Business"
    },
    {
      "name": "Steffan Tomlinson",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Steffan&last_name=Tomlinson",
      "role": "CFO",
      "title": "Chief Financial Officer"
    },
    {
      "name": "David Singleton",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=David&last_name=Singleton",
      "role": "CTO",
      "title": "Chief Technology Officer"
    },
    {
      "name": "Jeff Titterton",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Jeff&last_name=Titterton",
      "role": "CMO",
      "title": "Chief Marketing Officer"
    },
    {
      "name": "Eileen O'Mara",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Eileen&last_name=O%27Mara",
      "role": "OTHER",
      "title": "Chief Revenue Officer"
    },
    {
      "name": "Trish Walsh",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Trish&last_name=Walsh",
      "role": "OTHER",
      "title": "General Counsel"
    },
    {
      "name": "Rob McIntosh",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Rob&last_name=McIntosh",
      "role": "OTHER",
      "title": "Chief People Officer"
    },
    {
      "name": "William Alvarado",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=William&last_name=Alvarado",
      "role": "OTHER",
      "title": "Chief Business Officer"
    },
    {
      "name": "James Phillips",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=James&last_name=Phillips",
      "role": "DIRECTOR",
      "title": "Director of Financial Services"
    },
    {
      "name": "Christa Davies",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Christa&last_name=Davies",
      "role": "BOARD_MEMBER",
      "title": "Lead Independent Director"
    },
    {
      "name": "Bill Winters",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Bill&last_name=Winters",
      "role": "BOARD_MEMBER",
      "title": "Independent Director"
    },
    {
      "name": "Luciana Lixandru",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Luciana&last_name=Lixandru",
      "role": "BOARD_MEMBER",
      "title": "Independent Director"
    },
    {
      "name": "Matthew Huang",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Matthew&last_name=Huang",
      "role": "BOARD_MEMBER",
      "title": "Independent Director"
    },
    {
      "name": "Claire Hughes Johnson",
      "person_profile_url": "https://nubela.co/api/v1/employee/profile?employer_website=https%3A%2F%2Fstripe.com&first_name=Claire&last_name=Johnson",
      "role": "BOARD_MEMBER",
      "title": "Board Member"
    }
  ],
  "facebook_url": "https://facebook.com/StripeHQ",
  "founded_year": 2010,
  "funding": "https://nubela.co/api/v1/company/funding?website=https%3A%2F%2Fstripe.com",
  "industry": 45103010,
  "instagram_url": "https://instagram.com/stripehq",
  "logo_url": "https://nubela.co/api/v1/company/logo?website=https://stripe.com",
  "name": "Stripe",
  "public_listing": null,
  "similar_companies": "https://nubela.co/api/v1/competitor/listing?website=https%3A%2F%2Fstripe.com",
  "specialties": [
    "Payments",
    "Billing",
    "Financial Services",
    "Revenue Management",
    "Embedded Finance"
  ],
  "tagline": "Financial Infrastructure to Grow Your Revenue",
  "twitter_url": "https://x.com/stripe",
  "updates": "https://nubela.co/api/v1/company/updates?website=https%3A%2F%2Fstripe.com",
  "website": "https://stripe.com",
  "websites": [
    "https://stripe.com"
  ]
}

Company details that are fully packed! :) This data costs more to procure, so we have incremented the cost of the Company Profile Endpoint from 2 base credits to 3 base credits per API call.

Keep the feedback coming!

Most of these changes came about because you guys email me or reply to my emails. Please keep them coming and you'll see positive changes happening for you.

This API Endpoint takes special care not to read from private or proprietary datasets, and only from public sources, while doing its best to return a valid work email address. We do so as not to violate privacy laws or breach the Terms of Use or User Agreement of any sites.

That said, let me put it out there first: there are better contact enrichment services out there. But read on to find out the narrow use cases for which you should use NinjaPear's.

How well does it work?

To give you a transparent look at what to expect, we ran a fulfillment test across 20 diverse profiles. Our goal wasn't just to see if the API returns data, but to see how it handles real-world scenarios, including obscure domains and legacy companies.

Performance Summary

• Fulfillment Rate: 65% (13/20)
• Reliability: 100% (All 20 calls returned HTTP 200; no technical errors)
• Average Latency: ~9.3 seconds

Fulfillment Test Results (n=20)

There are other, better tools out there for contact enrichment

I'm going to be honest: Apollo or Clay will be infinitely better contact enrichment tools. NinjaPear isn't trying to be a contact enrichment product. We built the Work Email Endpoint simply because it is convenient for our users, and for those who want contact data strictly via public sources and not fished out from Chrome Extensions hooking into private Gmail accounts, like what Clearbit used to do.

In other words, use the Work Email Endpoint only if you do not already have access to better enrichment tools and you want 100% kosher contact data so that when a contact asks how you got their email, you can confidently say:

Hey, I found your email on the public web. You had either posted it somewhere in cleartext or your company has a known email pattern.

That said, honest to goodness: I built this because we are building out our AI agentic outbound sales / cold email pipeline and this was a missing piece. In fact, if you see our Competitors Listing Endpoint and Similar People Endpoint, you can see how we are gradually building out our own prospecting capabilities for our agentic pipelines ;)

How much does the Work Email Endpoint cost?

It costs 2 credits on a successful lookup—whenever we actually return something useful—and 0.5 credits if we return nothing. We charge a token amount to prevent denial-of-service attacks and also to cover our costs because we are performing live scraping and LLM calls on every API call. (See, we do not read from a contact database like the other guys).

Look up companies by name instead of website

A lot of customers have reached out asking if they can use a company name because they do not have the company website to perform various API calls. Well, as of today, yes you can!

For most API endpoints that take a company website, you can now provide a company name instead, whereby we will automagically look up the company's website. However, we still very much prefer that you use a website instead simply because it is more precise. There are many companies with the same or similar names globally, and NinjaPear works worldwide!

These are the API endpoints that now accept company names instead of a company website input:

• Customer Listing Endpoint
• Competitor Listing Endpoint
• Company Details Endpoint
• Employee Count Endpoint
• Company Updates Endpoint
• Company Funding Endpoint
• Person Profile Endpoint
• Similar People Endpoint

What is on the horizon

We have recently started mapping every damn product and service of all businesses worldwide into a giant database that you can look up. In other words, I want you to know that product data is coming soon, amongst others. I will keep you posted. I'm excited about this.

Because just think about it: short of a Google search and doing it manually, how can you find a "CRM that has OAuth and Gmail integration, with PAYG options" instantly? There exists AI deep research which will send an agent to make a web search and trawl the sites, but it will still only perform a top N SERP result crawl and not go deeper. I'm excited about this!

On top of that, there is something we're doing on the B2C front that will be a multi-year endeavor. I'll keep you posted on this too.

Questions? Send us an email at hello@nubela.co!

If you're asking is scraping LinkedIn legal in 2026, here's the short answer: public scraping is not automatically criminal after hiQ, but building a business on LinkedIn data is still not safe. Those are different statements. I learned that the expensive way. I was sued by LinkedIn. Proxycurl and I have since settled.

That commenter got to the point faster than most lawyers do. That is the whole article.

TL;DR

My actual answer to is scraping LinkedIn legal in 2026 is this:

• Narrow legal answer: scraping public LinkedIn pages is not automatically criminal under the CFAA after hiQ.
• Useful operator answer: LinkedIn data is still not safe to build on.
• Buyer answer: buying it from a vendor does not clean the chain of custody.
• Founder answer: the lawsuit risk is not the only problem. Discovery, customer notice, data deletion, and code deletion are the real problem.

Why I'm writing this

I was a named defendant in LinkedIn Corporation v. Nubela Pte. Ltd., Proxycurl LLC, Steven Goh, and Bach Le, filed in the Northern District of California on January 24, 2025, Case No. 3:25-cv-00828.

Proxycurl and I have settled with LinkedIn. I am not going to relitigate the case here. I am also not going to discuss settlement terms beyond that sentence.

What I can do is correct a mistake in how people used my earlier writing.

Back in 2019, I wrote a post called Is LinkedIn Scraping Legal? on the Nubela blog. That post made a narrow legal point about the CFAA and public data. I still think the narrow point was correct. The broader conclusion many people took from it, that LinkedIn data was therefore safe to build on, was not correct.

That distinction matters more in 2026 than it did in 2019.

The reason is simple. Once you are the defendant, the question changes. It stops being "can I win an internet argument about public data" and becomes "what can this plaintiff do to my company before the merits even matter".

That is a different question. It has a different answer.

Legal does not mean safe

People like the question is scraping LinkedIn legal because it sounds binary.

It is not binary.

At a minimum, you need four buckets:

1. Criminal law: can the government prosecute you?
2. Civil statutory claims: can a private plaintiff sue you under a statute like the CFAA, 18 U.S.C. § 1030(g)?
3. Contract claims: did you agree to terms and then violate them?
4. Other civil claims: unfair competition, misappropriation, trademark, fraud, and whatever else a plaintiff decides to stack in.

The case people keep citing is hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022).

What hiQ actually did was narrower than the folklore around it. It helped on the specific CFAA question around scraping public LinkedIn pages. It did not hold that scraping LinkedIn is generally safe. It did not erase contract claims. It did not erase California state-law claims. It did not tell buyers of LinkedIn-derived data that they were fine.

This is the part I underestimated for too long.

My 2019 post literally said: "You'd still have to be compliant with websites' ToS." That caveat was doing more work than the headline.

Readers remembered the headline. They forgot the caveat. I probably helped that happen.

So if you want the answer in plain English, here it is: public scraping may be outside one narrow theory of criminal or statutory liability, but that does not make your company safe from LinkedIn.

That is the frame I wish I had pushed harder from the start.

The User Agreement catches almost everyone

If you do anything in B2B data, this is the part you should read twice.

Most people talk about "public data" like it ends the discussion. It does not. The contract is where the danger lives.

LinkedIn's complaint said LinkedIn had more than one billion members at the time. If you have a LinkedIn account, had one in the past, or administer a LinkedIn Company Page, there is a good chance you are in contract land already.

And courts enforce click-through contracts all the time. This is not exotic law.

The scraping clause is not the only clause

Most people know there is a scraping clause in LinkedIn's User Agreement.

Section 8.2(2) says you cannot:

"Develop, support or use software, devices, scripts, robots or any other means or processes (such as crawlers, browser plugins and add-ons or any other technology) to scrape or copy the Services..."

Fine. Everyone expects that.

The clause more buyers should care about is Section 8.2(4):

"Copy, use, display or distribute any information (including content) obtained from the Services, whether directly or through third parties (such as search tools or data aggregators or brokers), without the consent of the content owner..."

That language matters. Especially the phrase "whether directly or through third parties ... data aggregators or brokers".

If you are a LinkedIn member and you buy a CSV, enrichment feed, or vendor dataset that contains LinkedIn-derived data, LinkedIn has a contract clause written for that fact pattern.

The data being public does not solve that.

The vendor being a respected vendor does not solve that.

The vendor being outside the US does not solve that.

There are two more clauses worth reading.

Section 8.2(11):

"Rent, lease, loan, trade, sell/re-sell or otherwise monetize the Services or related data or access to the same, without LinkedIn's consent."

Section 8.2(13):

"Use bots or other unauthorized automated methods to access the Services..."

This is not a narrow anti-scraping rule. It is a broad contractual perimeter.

Company Pages pull companies in too

A lot of founders forget this part.

If your company has a LinkedIn Page, the company did not just make a marketing asset. It clicked into a contract too.

LinkedIn's complaint walked through Nubela's and Proxycurl's Company Pages, and pointed out that creating those pages required agreement to LinkedIn's terms. The complaint also used forum-selection language to bring a Singaporean company and a Wyoming LLC into the Northern District of California.

This feels administrative until it doesn't.

Then it is jurisdiction.

Deleting your account does not make this go away

This is the part that usually gets silence.

Section 5 of LinkedIn's User Agreement contains a survival clause. It says sections including 6 and 8.2 survive termination.

Section 8.2 is the whole block that contains the scraping clause, the third-party broker clause, the resale clause, and the bots clause.

Section 6 is the dispute-resolution and governing-law machinery.

So no, you do not get to close your account and pretend the contract never happened.

The restrictions that matter here can outlive the account.

The practical consequence

If you are, or ever were, a LinkedIn member or a Page administrator, and you buy, use, resell, or build on LinkedIn-derived data, LinkedIn has a plausible breach-of-contract story against you.

I am being careful with that wording.

I am not saying every such case wins.

I am saying this is not a posture I would build a business on anymore.

That is not a court opinion. It is still useful. It tells you how people experience the lower rungs of enforcement.

What the complaint actually said

There is a point where abstract debate stops being useful.

Reading a complaint with your own name in it will do that.

Six claims at once

LinkedIn's complaint stacked six claims:

1. Breach of contract
2. Fraud and deceit under California Civil Code §§ 1572 and 1710
3. Computer Fraud and Abuse Act
4. California Unfair Competition Law under Bus. & Prof. Code § 17200
5. Trademark dilution by tarnishment under the Lanham Act
6. Misappropriation

This matters for a boring reason.

Even if you think two or three of those are weak, you still have to live with the rest while the case runs.

You do not need to lose every issue for the process to become punishing.

They quoted my own writing back at me

This was probably the cleanest lesson in the whole case.

LinkedIn quoted my own blog post back at me.

Complaint paragraph 60 quoted my old warning that scraping in disregard of terms of service is where things become tricky.

Complaint paragraph 61 quoted my old point that fake accounts used to access otherwise inaccessible data are obvious trouble.

It also quoted: "Clearly fraudulent activities are a big no-no in web scraping."

I wrote those lines as caveats. Litigation turned them into admissions.

That is not unfair. That is just how this works.

If you run a data business and you write publicly about legal boundaries, assume every sentence may come back later in a pleading.

Because it might.

The scary part was the remedy

The part founders should study is not the headline of the complaint. It is the prayer for relief.

Complaint paragraph 121 asked for an order requiring destruction of not just the allegedly scraped LinkedIn data, but also any data that was:

"inferred, aggregated, or synthesized as a result of data wrongfully extracted and copied from LinkedIn's website"

Paragraph 122 asked for destruction of software code and other tools for scraping LinkedIn.

Paragraph 123 asked for customer notification.

That is the piece people skip past too quickly.

If a plaintiff asks for raw data deletion, that is one thing.

If the plaintiff asks for deletion of downstream inferred and aggregated data, that is much worse. Now you are talking about feature stores, model training sets, enrichment outputs, derivative fields, and internal systems built on top of disputed source data.

If you trained a model on LinkedIn-derived data, you do not get to wave your hands and say the weights are spiritually separate from the input.

Maybe you win that argument eventually. Good luck enjoying the trip there.

Discovery is the punishment

This is the part non-lawyers tend to underweight.

The complaint is the public event. Discovery is the expensive event.

Every claim opens another door

Each claim creates another set of things the plaintiff can ask about.

Breach of contract means account creation, acceptance of terms, internal knowledge, use of tools, and downstream use.

CFAA means access patterns, infrastructure, logs, credentials, proxies, and notice.

Trademark means marketing copy, sales collateral, web pages, browser extensions, screenshots, and customer messaging.

Unfair competition and misappropriation can widen everything.

One case becomes several overlapping excavations into how your company actually runs.

What gets opened up

If you have never been through discovery, here is the operator version.

Potentially relevant material can include:

• email hits for terms like linkedin, scrape, extension, proxy, captcha, sales nav
• Slack messages and DMs
• Git history
• Jira tickets
• CI logs
• database schemas
• old backups
• proxy vendor contracts
• CAPTCHA solver invoices
• customer contracts tied to the data
• internal docs discussing data provenance
• browser extension prototypes
• prior entities and side projects run by founders

This is what I mean when I say legal does not mean safe.

You can have a clever merits argument and still be in a terrible business position.

The asymmetry is built in

LinkedIn's complaint was signed by Munger, Tolles & Olson.

That matters.

Large plaintiffs can fund long litigation campaigns. Startups generally cannot. Even profitable ones feel it.

This is not a morality tale. It is arithmetic.

Fight, settle, or default. Those are all bad doors.

The time to decide is before the data enters the building.

Buyers are not bystanders

A lot of buyers still think the vendor absorbs all the risk.

No.

If LinkedIn sues your vendor, you can get subpoenaed. Your diligence file matters. Your procurement emails matter. Your Slack jokes matter. Your model input docs matter.

If your internal posture was basically "we know where this probably came from but let's not ask too many questions", that is not a good position to discover later.

The grammar is rough. The business point is not.

Apollo and Seamless were the warning shot

Not every enforcement step starts with a complaint.

That matters.

Public reporting in 2025 noted that Apollo.io and Seamless.ai had their LinkedIn Company Pages removed. LeadGenius and LiGo both wrote about it as part of a broader crackdown on LinkedIn-adjacent scraping and extension behavior.

I am being careful here. I am sticking to the public reporting and the visible fact pattern.

The useful point is not some definitive claim about their internal conduct. The useful point is that LinkedIn showed it can act unilaterally, publicly, and before any public lawsuit appears.

That means there is an enforcement ladder.

My rough version of the ladder looks like this:

1. account restrictions
2. automation warnings
3. Company Page removals
4. cease-and-desist letters
5. federal complaint

The point is not that every company will climb every rung in order.

The point is that these rungs are real. We have seen them in the wild.

That quote is useful because it shows market perception in real time. People saw the page removals and immediately started asking a more serious question than "is scraping legal". They started asking what happens to users, extensions, and account risk.

That is the right direction.

There is also a practical point here for operators. If your product depends on goodwill from a platform you are contractually at odds with, that dependency is fragile even before a judge touches the case.

The only safe path I trust now

This is where I changed my mind.

If you are building, using, or scaling with B2B data, I think the only durable answer is this:

Use data that does not have LinkedIn as a source.

Not "mostly not".

Not "we only enrich with it".

Not "we bought it rather than scraped it".

Not "we deleted it later".

None of that is clean enough.

What zero LinkedIn data actually means

When I say zero LinkedIn data, I mean something strict enough to survive diligence and strict enough to survive discovery.

That means:

• no LinkedIn-sourced rows in prod, staging, notebooks, or dev databases
• no LinkedIn URLs, member IDs, or copied fields in code paths
• no LinkedIn content in training sets, evals, prompt corpora, or fine-tunes
• no vendor whose vendor touched LinkedIn
• no Chrome extensions touching linkedin.com
• no internal prototypes that hit LinkedIn and then got "deleted"
• no reachable Git blobs containing LinkedIn-specific scraping code
• no forgotten S3 backups with stale data dumps

This sounds severe.

It is severe.

That is because discovery is severe.

If you want to be able to say under oath that LinkedIn data was never part of the product, then that needs to be true in a boring, literal, systems-engineering sense.

Not in a vibes sense.

Why I'm building NinjaPear this way

This is one reason I am building NinjaPear with a zero-LinkedIn-data posture.

The point is not that I suddenly stopped caring about B2B data. I care about it more than ever.

The point is that I no longer think LinkedIn is a durable substrate for a company.

That is why products like the Customer API, Company Monitor, and Pricing sit on a different posture entirely. The data model has to work without LinkedIn in ingestion, training, enrichment, or internal tooling.

This is not me trying to sneak in a sales pitch.

It is the conclusion the lawsuit forced me to take seriously.

I spent years arguing about legal boundaries. I now care more about whether a company can still exist in 10 years without carrying this particular exposure around.

For me, that answer requires a clean break.

Why I do not keep a LinkedIn profile anymore

I want to be explicit here because people misread this.

Neither NinjaPear nor I maintain a LinkedIn profile now. No member account. No Company Page. No Showcase Page.

The reason is not that we want to scrape LinkedIn. We do not. We will not.

The reason is that if the User Agreement is broad, and its relevant restrictions survive termination, then the lowest-exposure posture is simply not to be a party to that contract anymore.

Some readers will think that is too strict.

Fair enough.

After being named in a complaint, strictness started looking cheaper.

My actual answer

So, one more time, is scraping LinkedIn legal in 2026?

My answer is:

• If you mean criminally illegal under the CFAA, public scraping is not automatically illegal after hiQ.
• If you mean safe to build a business on, no, I do not think it is safe.
• If you mean safe because a vendor sold it to you, also no.
• If you mean safe because you only enriched or modeled on top of it, still no.

That is the biggest thing I changed my mind about.

I used to think the narrow legal answer carried more practical protection than it actually does.

It doesn't.

The question I would ask now is much uglier and much better:

If LinkedIn's lawyers subpoenaed everything tomorrow, what would they find?

If the answer includes uncertain provenance, browser extensions touching LinkedIn, old Git history, model training on LinkedIn-derived features, or vendor contracts you have never really audited, then you have work to do.

Probably this week.

This article is not legal advice. You should talk to your own counsel for your own facts.

But as operator advice, I am comfortable being blunt: do not build your company on LinkedIn data.

Start by auditing what you already have. Then remove what you cannot defend. Then build future systems so this problem does not come back.

If you are starting from scratch, build on sources that do not route through LinkedIn at all. That is the only answer I trust now.

References

1. Nubela, Is LinkedIn Scraping Legal? https://nubela.co/blog/is-linkedin-scraping-legal/
2. hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022).
3. LinkedIn Corporation v. Nubela Pte. Ltd., Proxycurl LLC, Steven Goh, and Bach Le, Case No. 3:25-cv-00828, Complaint (N.D. Cal. Jan. 24, 2025). Matter subsequently settled.
4. LinkedIn User Agreement, effective Nov. 20, 2024. https://www.linkedin.com/legal/user-agreement
5. LeadGenius, LinkedIn's Crackdown on Data Scrapers: Why Apollo.io and Seamless.ai Were Targeted, and Who's Next https://www.leadgenius.com/resources/linkedins-crackdown-on-data-scrapers-why-apollo-io-and-seamless-ai-were-targeted--and-whos-next
6. LiGo, LinkedIn Bans Apollo & Seamless: Major Data Scraping Crackdown https://ligo.ertiqah.com/blog/linkedins-major-crackdown-on-data-scraping-apollo-and-seamless-company-pages-gone
7. 18 U.S.C. § 1030(g). https://www.law.cornell.edu/uscode/text/18/1030

A customer sought out recommendations for his problem: “I have been experimenting with NinjaPear using my AI agents to find investors and leads for my company.” In this article, I’m going to show you how to build a full agentic lead generation system with PydanticAI, NinjaPear, and a small set of supporting tools, including the exact 4 loops, the code structure, and the GitHub project you can ship.

What this guide does

This is a developer guide for look alike prospecting inside an agentic SDR system.

It covers four loops:

• Competitor → Customers: turn one known company into additive prospect accounts.
• CRM Account → Competitors: widen your account universe from closed-won seeds.
• CRM Contact → Similar People: turn one good contact into many role-adjacent people at relevant companies.
• Company → Updates: rank the best prospects by visible timing signals.

That is the whole job here. I’m going to show the loops, the code, the sample responses, the models, and the guardrails that keep this from becoming a fancy way to buy bad leads faster.

Lookalike prospecting, without the bullshit

Look alike prospecting is not “find me companies with similar headcount.” It is generating new accounts or people that resemble proven wins across fit, context, and timing. Most tools stop at fit. That is why most outputs feel generic.

Most lookalike prospecting products are just firmographic cloning with an AI label attached. They fail for ordinary reasons: dirty seeds, weak source signals, no suppression layer, and scoring logic nobody can explain once a rep asks why a company is on the list.

Clean input is boring. That is why it works. Start with closed-won first. Split by use case. Exclude existing customers, churned accounts, open opps, partners, agencies, and test junk before you enrich anything. A 20-account clean seed will beat a 2,000-account blended mess almost every time.

The signal stack is not equal. Firmographics are table stakes. Technographics add context. Relationship data is stronger. Trigger data handles timing. If you already have customer work emails in CRM, Similar People is usually your best 1→N move.

The 4 agent loops

The system has four loops because there are four separate problems.

1. Competitor to customers gives you fast account expansion.
2. CRM accounts to competitors gives you clean market widening.
3. CRM contacts to similar people gives you additive people discovery.
4. Triggers to outreach gives you timing.

Do not collapse all four into one big pipeline on day one. Keep them separate. It makes debugging easier, measurement easier, and failure less ambiguous.

Loop 1: Competitor to customers

Problem: You know a competitor or adjacent company and want a prospect list fast.

Solution: Use the Customer API customer listing endpoint to find companies already buying from that vendor or sitting in its ecosystem.

This endpoint is a good starting point because it returns three relationship buckets: customers, investors, and partner_platforms. The docs also matter here. Cost is 1 credit per request + 2 credits per company returned. quality_filter defaults to true, which filters junk TLDs and unreachable sites. Good default.

from src.clients.ninjapear import NinjaPearClient
from src.models import ProspectAccount

client = NinjaPearClient()
response = client.get_customer_listing("https://stripe.com")
accounts = [
    ProspectAccount.from_customer_listing(item, source="customer_listing")
    for item in response["customers"]
]

Sample response, using the same shape as NinjaPear docs:

{
  "customers": [
    {
      "name": "Apple",
      "description": "Apple Inc. designs, manufactures, and markets smartphones, personal computers, tablets, wearables, and accessories worldwide.",
      "tagline": "Think different.",
      "website": "https://www.apple.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Fwww.apple.com",
      "id": "abc123",
      "industry": 45202030,
      "specialties": ["Technology", "Consumer Electronics"],
      "x_profile": "https://x.com/Apple"
    }
  ],
  "investors": [
    {
      "name": "Sequoia Capital",
      "description": "Sequoia Capital is a venture capital firm focused on technology companies.",
      "tagline": null,
      "website": "https://www.sequoiacap.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Fwww.sequoiacap.com",
      "id": "def456",
      "industry": 40203010,
      "specialties": ["Venture Capital", "Growth Equity"],
      "x_profile": "https://x.com/sequoia"
    }
  ],
  "partner_platforms": [
    {
      "name": "Amazon Web Services",
      "description": "Amazon Web Services provides cloud computing platforms and APIs.",
      "tagline": null,
      "website": "https://aws.amazon.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Faws.amazon.com",
      "id": "ghi789",
      "industry": 45101010,
      "specialties": ["Cloud Computing", "Infrastructure"],
      "x_profile": "https://x.com/awscloud"
    }
  ],
  "next_page": "https://nubela.co/api/v1/customer/listing?website=https://www.stripe.com&cursor=abc123"
}

The flow is simple:

• input website
• customer list
• normalize
• suppress existing CRM accounts
• score

Expected normalized output:

{
  "name": "Apple",
  "website": "https://www.apple.com",
  "industry": "45202030",
  "source": "customer_listing",
  "source_evidence": [
    "Returned by customer_listing",
    "Company id: abc123"
  ],
  "fit_score": 0.65,
  "relationship_score": 0.85,
  "timing_score": 0.25
}

A workable outreach angle is short and specific: you already sell into the same ecosystem as Stripe, so this is not a random account pulled from firmographic filters.

Loop 2: CRM accounts to competitors

Problem: You have closed-won accounts in CRM and want to widen the account universe around them.

Solution: Use the Competitor Listing Endpoint on each CRM account website, merge results, dedupe, suppress, score.

This is the cleanest 0→1 account expansion loop in the stack. It starts with proven wins. That matters more than people think.

from src.clients.ninjapear import NinjaPearClient
from src.scoring import score_account

client = NinjaPearClient()

for website in seed_account_websites:
    competitors = client.get_competitor_listing(website)
    for comp in competitors["competitors"]:
        scored = score_account(comp, source="competitor_listing")
        if scored.total_score >= 0.72:
            save_candidate(scored)

Sample response:

{
  "competitors": [
    {
      "name": "Adyen",
      "website": "https://www.adyen.com",
      "description": "Financial technology platform for enterprise businesses.",
      "competition_type": "product_category_overlap",
      "reason": "Both companies offer payment infrastructure and enterprise checkout products.",
      "industry": 40204010
    },
    {
      "name": "PayPal",
      "website": "https://www.paypal.com",
      "description": "Digital payments platform for consumers and merchants.",
      "competition_type": "organic_seo_overlap",
      "reason": "Both companies rank for overlapping payments-related organic search terms.",
      "industry": 40204010
    }
  ],
  "next_page": null
}

Expected scored output with evidence retained:

This is the part I like about competitor data when it is explicit. You keep the reason. You do not throw it away. Product overlap usually deserves more weight than shared SEO adjacency because it points to budget competition, not just similar search surfaces.

That quote is not about competitors directly, but it points at the same thing: most list quality problems are filtering problems, not enrichment problems.

Loop 3: CRM contacts to similar people

Problem: You already have customer contacts in CRM and want additive 1→N growth.

Solution: Use the Similar People Endpoint from work emails to find similar roles at other relevant companies.

This is the real 1→N motion if your CRM has actual work emails. Not guessed emails. Real ones.

from src.clients.ninjapear import NinjaPearClient
from src.models import ProspectPerson

client = NinjaPearClient()

for work_email in customer_contact_emails:
    similar_people = client.get_similar_people(work_email=work_email)
    for person in similar_people["results"]:
        prospect = ProspectPerson.from_similar_person(person)
        if not is_suppressed_person(prospect):
            save_person(prospect)

Sample response:

{
  "results": [
    {
      "full_name": "Will Cannon",
      "first_name": "Will",
      "last_name": "Cannon",
      "bio": "Founder building B2B lead generation software.",
      "work_email": "[email protected]",
      "role": "Founder & CEO",
      "company_name": "UpLead",
      "company_website": "https://uplead.com",
      "city": "Walnut",
      "country": "US",
      "x_handle": "willcannon",
      "input_role": "Founder & CEO"
    },
    {
      "full_name": "Henry Schuck",
      "work_email": "[email protected]",
      "role": "CEO & Chairman",
      "company_name": "ZoomInfo",
      "company_website": "https://zoominfo.com",
      "city": "Vancouver",
      "country": "US",
      "input_role": "Founder & CEO"
    }
  ]
}

Expected normalized output:

{
  "full_name": "Will Cannon",
  "work_email": "[email protected]",
  "company_website": "https://uplead.com",
  "role": "Founder & CEO",
  "source": "similar_people",
  "source_evidence": [
    "Matched as similar person to Founder & CEO"
  ],
  "account_score": 0.76,
  "person_score": 0.80
}

This is the loop where the system starts to feel good, because you are transferring buyer patterns from known-good contacts instead of guessing titles from a huge database.

The published Similar People benchmarks are useful because they show where the endpoint is strongest:

• Tim Cook / Apple: 18 attempted, 18 found, 100% yield
• Elon Musk / Tesla: 11 attempted, 11 found, 100% yield
• Patrick Collison / Stripe: 19 attempted, 16 found, 84% yield
• Bryan Irace / Stripe engineering manager: 19 attempted, 12 found, 63% yield
• Robert Heaton / Stripe MTS: 65 attempted, 36 found, 55% yield

That decay lower in the org chart is normal. Executives are more public. Mid-level people are noisier.

And yes, here is the context-specific example outreach angle from the plan:

“Hey! Your competitor from Company X just joined NinjaPear. It happens that NinjaPear has a feature to extract customers of your company. Would you like to join NinjaPear to also gain an edge against your competitors?”

Use that as an example of context, not default copy. If the agent cannot show the evidence, the rep should not send the email.

Loop 4: Triggers to outreach

Problem: Your lookalikes are plausible, but you still do not know who to contact now.

Solution: Use Company Updates or Monitor signals to prioritize accounts showing real change.

Trigger data is a ranking layer. It is not a prospect source.

from src.clients.ninjapear import NinjaPearClient
from src.outreach import draft_outreach

client = NinjaPearClient()

updates = client.get_company_updates("https://example.com")
for event in updates["results"]:
    if event["category"] in {"website update", "blog", "x"}:
        draft = draft_outreach(account, event)
        save_draft(draft)

Sample response:

{
  "results": [
    {
      "title": "Pricing page updated, new Enterprise tier added",
      "link": "https://example.com/pricing",
      "category": "website update",
      "pub_date": "Thu, 27 Feb 2026 07:00:00 GMT",
      "summary": "Enterprise packaging was added to the pricing page."
    },
    {
      "title": "Announcing global payments expansion",
      "link": "https://example.com/blog/global-payments",
      "category": "blog",
      "pub_date": "Thu, 27 Feb 2026 10:00:00 GMT",
      "summary": "The company announced broader market coverage for payments."
    }
  ]
}

Expected outreach draft:

{
  "subject": "Saw this at ExampleCo",
  "body": "Saw the update: Pricing page updated, new Enterprise tier added. Usually that means the team is changing packaging, priorities, or buyer motion.",
  "evidence": [
    "Returned in customer listing for Stripe",
    "Trigger: Pricing page updated, new Enterprise tier added"
  ],
  "confidence": 0.78,
  "requires_review": true
}

The Company Monitor docs are refreshingly specific on credit usage:

• 20 weekly targets: ~346 credits/month
• 10 daily competitor targets: ~1,203 credits/month
• 5 daily prospect accounts, blog + X only: ~453 credits/month

That is enough to budget the loop without guessing.

A lot of people are building #GTM engines now, but the real effectiveness comes down to which market signals you track and how strong your market intelligence is. In B2B, we’ve found that not all signals are equal.

— lev8 (@lev8ai) Mon Apr 13 03:02:09 +0000 2026

That is the right framing. Not all signals are equal. A pricing page change is usually more actionable than another vague “high intent” badge.

Repo structure

Keep this concrete.

Push from the real project root, not from a parent wrapper folder. This sounds obvious because it is obvious. People still get it wrong.

README.md
.env.example
pyproject.toml
data/
  closed_won_accounts.csv
  crm_contacts.csv
  suppression_accounts.csv
  suppression_people.csv
examples/
  sample_customer_listing.json
  sample_competitor_listing.json
  sample_similar_people.json
  sample_updates.json
src/
  config.py
  models.py
  scoring.py
  suppressions.py
  outreach.py
  clients/
    ninjapear.py
  agents/
    coordinator.py
    research_agent.py
    scoring_agent.py
    copy_agent.py
  pipelines/
    loop_competitor_to_customers.py
    loop_crm_to_competitors.py
    loop_contacts_to_similar_people.py
    loop_triggers_to_outreach.py
tests/
  test_scoring.py
  test_suppressions.py

There is no reason to bury the project inside a wrapper folder. If someone clones the repo, they should immediately see README.md, pyproject.toml, src/, data/, and tests/ at the top level.

That is exactly why repo structure matters. If the code path is messy, the workflow will be messy too.

Core Pydantic models

Keep this practical. The point of Pydantic here is not ceremony. It is to force evidence to stay attached to the record.

SeedAccount

Fields: name, website, segment, source, is_closed_won, arr_band

SeedContact

Fields: full_name, work_email, company_website, role, seniority

ProspectAccount

Fields: name, website, industry, source, source_evidence, fit_score, relationship_score, timing_score

ProspectPerson

Fields: full_name, work_email, company_website, role, source, source_evidence, account_score, person_score

OutreachDraft

Fields: subject, body, evidence, confidence, requires_review

from pydantic import BaseModel, HttpUrl
from typing import List, Optional

class ProspectAccount(BaseModel):
    name: str
    website: HttpUrl
    industry: Optional[str] = None
    source: str
    source_evidence: List[str] = []
    fit_score: float = 0.0
    relationship_score: float = 0.0
    timing_score: float = 0.0

If a prospect loses its evidence trail between raw JSON and outbound draft, the model failed.

NinjaPear client wrapper

Use a thin wrapper. Do not build a fake framework.

Also, if you are building this with a coding agent, point it to https://nubela.co/llms-full.txt. The docs are already structured for LLMs and include endpoint coverage, rate limits, pagination, timeout guidance, and examples.

import os
import httpx

class NinjaPearClient:
    def __init__(self, api_key: str | None = None):
        self.api_key = api_key or os.environ["NINJAPEAR_API_KEY"]
        self.base_url = "https://nubela.co"
        self.headers = {"Authorization": f"Bearer {self.api_key}"}

    def get_customer_listing(self, website: str):
        r = httpx.get(
            f"{self.base_url}/api/v1/customer/listing",
            params={"website": website},
            headers=self.headers,
            timeout=100.0,
        )
        r.raise_for_status()
        return r.json()

Then add the obvious follow-up methods for competitor listing, similar people, and company updates.

The API behavior that matters:

• normal rate limit is 300 requests/minute
• the effective window is 1,500 requests per 5 minutes
• trial accounts are limited to 2 requests/minute
• long-running endpoints can take 30 to 60 seconds
• recommended timeout is 100 seconds
• 429 needs exponential backoff
• 404 is charged, failed requests are otherwise not charged

Those details change how you write the client. They are not side notes.

Scoring and suppressions

One short intro and then code.

Make scoring simple enough that a human can understand it.

def score_account(account) -> float:
    return round(
        (account.fit_score * 0.40)
        + (account.relationship_score * 0.35)
        + (account.timing_score * 0.25),
        4,
    )

That weighting is fine as a default because it gives fit first position, gives relationship data real weight, and stops timing from hijacking the list.

def is_suppressed_account(account, suppression_websites: set[str]) -> bool:
    return str(account.website) in suppression_websites

Suppress before enrichment:

• existing customers
• open opps
• churned accounts you should not re-enter yet
• partners
• agencies
• internal domains
• obvious bad domains

If you enrich first and suppress later, you are paying to make junk more detailed.

I am also skeptical of black-box intent. If the system cannot tell you why an account is hot, the score is decorative.

Outreach generation

The copy agent should only use evidence the system can show.

SYSTEM_PROMPT = """
Write short outbound emails using only the supplied evidence.
Do not invent facts.
If evidence is weak, say so and mark requires_review=true.
"""

def build_evidence_block(account, event=None):
    evidence = list(account.source_evidence)
    if event:
        evidence.append(f"Trigger: {event['title']}")
    return evidence

That is the whole rule. Do not let the model improvise facts because it has a good tone. Tone does not save a false claim.

How to run the project

Practical checklist:

uv venv
source .venv/bin/activate
uv pip install -e .
cp .env.example .env
export NINJAPEAR_API_KEY=your_key_here
python -m src.pipelines.loop_competitor_to_customers
python -m src.pipelines.loop_crm_to_competitors
python -m src.pipelines.loop_contacts_to_similar_people
python -m src.pipelines.loop_triggers_to_outreach

And yes, inspect the full endpoint docs in https://nubela.co/llms-full.txt when wiring parameters, pagination, retries, and endpoint-specific schemas. The article gives you the architecture. The docs give you the sharp edges.

What to measure

Track this by loop source, not just in aggregate:

• suppression rate
• enrichment rate
• reply rate
• meeting rate
• opportunity rate
• average evidence depth per record

If Similar People produces fewer rows but twice the meetings, that is the better loop.

Mistakes to avoid

Keep this short.

• giant blended seed lists
• enriching too early
• no suppression layer
• blind trust in black-box intent
• full auto before review
• outreach that cites evidence the system cannot prove
• pushing a GitHub repo with the real project buried in a nested folder like some kind of maniac

Most failures here are not model failures. They are operating mistakes.

If you want the right next step, clone the repo, point your coding agent at https://nubela.co/llms-full.txt, and run the four loops against your own closed-won seeds first. That will tell you more than another week spent tuning a giant dirty list.

Most lead generation content is useless if you need to actually build the thing. A customer sought out recommendations for his problem: “I have been experimenting with NinjaPear using my AI agents to find investors and leads for my company.” In this guide, I’m going to show you how to build a full agentic lead generation system with PydanticAI, NinjaPear, and a small set of supporting tools, including the exact 4 loops, the code structure, and the GitHub project you can ship.

Build the system first

If I were a founder building outbound against Stripe and Shopify, I would not start with prompts. I would start with a system.

These are the 4 loops:

• Loop 1, customer loop: pull likely customers of Stripe and Shopify, because a competitor's customer is better evidence than a random firmographic export
• Loop 2, competitor loop: expand into adjacent companies, because most teams do not have a lead shortage, they have a market map shortage
• Loop 3, people loop: find role-alike buyers only after account qualification, because people-first prospecting usually gives you a larger pile of irrelevant contacts
• Loop 4, timing loop: enrich and monitor those accounts for changes, because without timing you do not have agentic lead generation, you have a nicer spreadsheet

That is what this guide does. It wires those four loops into one workflow and shows the code and response shapes I would use if I were trying to sell into the same market as Stripe and Shopify.

The whole workflow is this:

seed domains -> customer loop -> competitor loop -> people loop -> timing loop -> queue

And the main() is boring on purpose.

def main():
    seeds = ["https://stripe.com", "https://shopify.com"]
    accounts = pull_competitor_customers(seeds)
    accounts = expand_competitors(accounts)
    people = find_similar_people(accounts)
    enriched = enrich_and_monitor(accounts, people)
    queue = build_outreach_queue(enriched)
    return queue

That is enough structure to build around.

When I was running FluxoMetric, this was my mistake for a while. I thought better modeling would fix bad market inputs. It does not. It just gives you a cleaner wrong answer.

The stack

Keep the stack simple:

• NinjaPear for company, customer, competitor, people, funding, updates, and monitor data
• PydanticAI for orchestration, typed tools, and validated outputs
• OpenRouter as the model gateway
• Mock helpers for email verification and email sending

Install what you need:

pip install ninjapear pydantic-ai httpx pydantic python-dotenv

Minimal settings model:

from pydantic import BaseModel
import os

class Settings(BaseModel):
    ninjapear_api_key: str
    openrouter_api_key: str

settings = Settings(
    ninjapear_api_key=os.environ["NINJAPEAR_API_KEY"],
    openrouter_api_key=os.environ["OPENROUTER_API_KEY"],
)

PydanticAI through OpenRouter:

from pydantic_ai import Agent
from pydantic_ai.models.openrouter import OpenRouterModel
from pydantic_ai.providers.openrouter import OpenRouterProvider

model = OpenRouterModel(
    "anthropic/claude-sonnet-4-5",
    provider=OpenRouterProvider(api_key=settings.openrouter_api_key),
)
agent = Agent(model)

My opinion here is straightforward. The model matters less than the data and the wiring. Most agentic lead generation demos fail because they are toys sitting on bad data.

The NinjaPear docs are useful here because they tell you the operational limits up front:

• up to 300 requests/minute
• a 1,500 request burst window over 5 minutes
• trial accounts limited to 2 requests/minute
• many endpoints take 30 to 60 seconds
• recommended timeout: 100 seconds

That is enough to design the pipeline without guessing.

Loop 1: Pull competitor customers

If I were selling something that should land in the same accounts as Stripe or Shopify, this is where I would start.

A competitor’s customer is usually a better lead than a giant stale firmographic export. Not because it is magical. Because it is evidence of actual category demand.

Seed your domains

Start with companies your buyer already compares you against.

seeds = [
    "https://stripe.com",
    "https://shopify.com",
]

Do not start with 500 domains. Start with 2 to 10 and make sure the plumbing works.

Call Customer Listing

Use the Customer Listing API.

These details matter:

• Endpoint: GET /api/v1/customer/listing
• Cost: 1 credit/request + 2 credits/company returned
• Empty results can still cost you
• quality_filter=true should stay on unless you want junk
• Pagination uses next_page and cursor
• page_size supports 1 to 200, default 200

Official SDK setup:

import ninjapear

configuration = ninjapear.Configuration(
    host="https://nubela.co",
    access_token="YOUR_API_KEY",
)

with ninjapear.ApiClient(configuration) as api_client:
    api = ninjapear.CustomerAPIApi(api_client)
    response = api.get_customer_listing(
        website="https://www.stripe.com",
        quality_filter=True,
    )

Wrapper I would keep in a project:

import ninjapear
from urllib.parse import urlparse
from pydantic import BaseModel

class ProspectAccount(BaseModel):
    source_company: str
    relationship_type: str
    name: str
    website: str | None
    description: str | None = None
    specialties: list[str] = []
    x_profile: str | None = None


def normalize_domain(url: str) -> str:
    return urlparse(url).netloc.replace("www.", "")


def get_customer_listing(api_client, website: str, cursor: str | None = None, page_size: int = 200, quality_filter: bool = True):
    api = ninjapear.CustomerAPIApi(api_client)
    return api.get_customer_listing(
        website=website,
        cursor=cursor,
        page_size=page_size,
        quality_filter=quality_filter,
    )

Pagination helper:

from urllib.parse import urlparse, parse_qs


def paginate_customer_listing(api_client, website: str, page_size: int = 200):
    cursor = None
    while True:
        response = get_customer_listing(
            api_client,
            website=website,
            cursor=cursor,
            page_size=page_size,
            quality_filter=True,
        )
        yield response
        next_page = response.get("next_page") if isinstance(response, dict) else getattr(response, "next_page", None)
        if not next_page:
            break
        cursor_values = parse_qs(urlparse(next_page).query).get("cursor", [])
        cursor = cursor_values[0] if cursor_values else None
        if not cursor:
            break

Parse only what matters

For lead generation, I do not treat all relationship types the same.

Flatten the response into one account model:

def flatten_customer_response(source_company: str, payload) -> list[ProspectAccount]:
    rows = []
    data = payload.to_dict() if hasattr(payload, "to_dict") else payload
    for key, relationship_type in {
        "customers": "customer",
        "investors": "investor",
        "partner_platforms": "partner_platform",
    }.items():
        for item in data.get(key, []) or []:
            rows.append(
                ProspectAccount(
                    source_company=source_company,
                    relationship_type=relationship_type,
                    name=item.get("name", "Unknown"),
                    website=item.get("website"),
                    description=item.get("description"),
                    specialties=item.get("specialties") or [],
                    x_profile=item.get("x_profile"),
                )
            )
    return rows

Sample response shape from the docs:

{
  "customers": [
    {
      "name": "Apple",
      "description": "Apple Inc. designs, manufactures, and markets smartphones, personal computers, tablets, wearables, and accessories worldwide.",
      "tagline": "Think different.",
      "website": "https://www.apple.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Fwww.apple.com",
      "id": "abc123",
      "industry": 45202030,
      "specialties": ["Technology", "Consumer Electronics"],
      "x_profile": "https://x.com/Apple"
    }
  ],
  "investors": [
    {
      "name": "Sequoia Capital",
      "description": "Sequoia Capital is a venture capital firm focused on technology companies.",
      "tagline": null,
      "website": "https://www.sequoiacap.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Fwww.sequoiacap.com",
      "id": "def456",
      "industry": 40203010,
      "specialties": ["Venture Capital", "Growth Equity"],
      "x_profile": "https://x.com/sequoia"
    }
  ],
  "partner_platforms": [
    {
      "name": "Amazon Web Services",
      "description": "Amazon Web Services provides cloud computing platforms and APIs.",
      "tagline": null,
      "website": "https://aws.amazon.com",
      "company_logo_url": "https://nubela.co/api/v1/company/logo?website=https%3A%2F%2Faws.amazon.com",
      "id": "ghi789",
      "industry": 45101010,
      "specialties": ["Cloud Computing", "Infrastructure"],
      "x_profile": "https://x.com/awscloud"
    }
  ],
  "next_page": "https://nubela.co/api/v1/customer/listing?website=https://www.stripe.com&cursor=abc123"
}

That is enough to build a real first pass.

What I would not do is dump investors and partner platforms straight into the outreach queue.

That is the practical case for starting with competitor customer data instead of a shared database.

Dedupe the account list

Dedupe by normalized domain.

from collections import OrderedDict


def dedupe_accounts(accounts: list[ProspectAccount]) -> list[ProspectAccount]:
    deduped = OrderedDict()
    for account in accounts:
        key = normalize_domain(account.website) if account.website else account.name.lower()
        if key not in deduped:
            deduped[key] = account
    return list(deduped.values())

Most teams do not have a lead generation shortage. They have a data hygiene shortage.

Loop 2: Expand competitors

If Stripe and Shopify are your starting map, this loop is how you widen the search without turning it into random noise.

Find adjacent competitors

Use the Competitor Listing endpoint.

Relevant details from the docs:

• Endpoint: GET /api/v1/competitor/listing
• Cost: 2 credits per competitor returned
• There is a minimum request cost, so be selective

Wrapper:

def get_competitors(api_client, website: str, cursor: str | None = None, page_size: int = 50):
    api = ninjapear.CompetitorAPIApi(api_client)
    return api.get_competitor_listing(website=website, cursor=cursor, page_size=page_size)

Sample response shape:

{
  "competitors": [
    {
      "company_name": "Adyen",
      "website": "https://www.adyen.com",
      "product_category_overlap": ["payment processing", "checkout", "fraud tools"],
      "organic_seo_overlap": ["payment gateway", "merchant of record"]
    },
    {
      "company_name": "Checkout.com",
      "website": "https://www.checkout.com",
      "product_category_overlap": ["payments infrastructure"],
      "organic_seo_overlap": ["online payments"]
    }
  ],
  "next_page": null
}

This is enough. You have adjacent companies and the reasons they overlap.

Expand one layer at a time

Do not recurse forever.

def expand_competitors(api_client, seed_domains, max_depth=1):
    visited = set()
    frontier = list(seed_domains)
    discovered = []
    depth = 0

    while frontier and depth < max_depth:
        next_frontier = []
        for website in frontier:
            if website in visited:
                continue
            visited.add(website)
            payload = get_competitors(api_client, website=website)
            data = payload.to_dict() if hasattr(payload, "to_dict") else payload
            for item in data.get("competitors", []) or []:
                comp_website = item.get("website")
                if comp_website and comp_website not in visited:
                    discovered.append(comp_website)
                    next_frontier.append(comp_website)
        frontier = next_frontier
        depth += 1

    return discovered

One layer is usually enough to improve coverage without turning the account set into mush.

Track provenance

Every discovered account should carry provenance:

• which seed exposed it
• which competitor chain exposed it
• what relationship type brought it into the graph

That gives you something to score later. It also gives you something real to message against.

Stop the loop early

Use three brakes:

• max_depth
• domain dedupe
• account caps

If you do not cap this, you end up exploring the whole category and calling it prospecting.

# pseudocode
async for website in frontier:
    if website not in visited and len(discovered) < account_cap:
        fetch competitor listing
        append new domains

That is the argument for market mapping. You need better discovery, not just another seat on the same database.

Loop 3: Find similar people

This is the people layer. It should happen after account filtering.

Start with the account

Only run people discovery on accounts that already passed some fit threshold.

For example:

• competitor customer
• decent headcount band
• recent public updates
• category relevance from the source chain

Do that first. Then go looking for humans.

Pull role-alike people

Use the Similar People endpoint.

class ProspectPerson(BaseModel):
    account_domain: str
    full_name: str | None = None
    role: str | None = None
    work_email: str | None = None
    x_handle: str | None = None
    score: float = 0.0

def find_similar_people(api_client, employer_website: str, role: str):
    api = ninjapear.EmployeeAPIApi(api_client)
    return api.get_similar_people(employer_website=employer_website, role=role)

If I were building this for a payments-adjacent product, I would start with one clean role like Head of Revenue Operations or VP Sales Operations.

Sample response shape:

{
  "results": [
    {
      "full_name": "Jane Doe",
      "role": "Head of Revenue Operations",
      "work_email": "[email protected]",
      "x_handle": "janedoe",
      "x_profile_url": "https://x.com/janedoe",
      "employer_website": "https://shopify.com"
    },
    {
      "full_name": "Alex Kim",
      "role": "VP Sales Operations",
      "work_email": null,
      "x_handle": null,
      "x_profile_url": null,
      "employer_website": "https://www.apple.com"
    }
  ]
}

Enrich the person record

Then use the Person Profile endpoint.

It can resolve from:

• work email
• name + company
• role + company

NinjaPear’s published match-rate guidance is useful:

Wrapper:

def get_person_profile(api_client, work_email=None, employer_website=None, role=None, first_name=None, last_name=None):
    api = ninjapear.EmployeeAPIApi(api_client)
    return api.get_employee_profile(
        work_email=work_email,
        employer_website=employer_website,
        role=role,
        first_name=first_name,
        last_name=last_name,
    )

Sample response shape:

{
  "id": "a3xK9mP2",
  "full_name": "Patrick Collison",
  "first_name": "Patrick",
  "last_name": "Collison",
  "bio": "Co-founder and CEO of Stripe",
  "profile_pic_url": "https://pbs.twimg.com/...",
  "country": "IE",
  "city": "IELIM",
  "x_handle": "patrickc",
  "x_profile_url": "https://x.com/patrickc",
  "personal_website": "https://patrickcollison.com",
  "work_experience": [
    {
      "role": "Co-founder & CEO",
      "company_name": "Stripe",
      "company_website": "stripe.com",
      "start_date": "2010-01",
      "end_date": null
    }
  ],
  "education": [
    {
      "major": "B.S. Mathematics",
      "school": "MIT",
      "start_date": "2006-09",
      "end_date": "2009-06"
    }
  ]
}

Build the contact queue

Turn the best accounts into a contact queue.

def build_contact_queue(api_client, accounts, target_role="Head of Revenue Operations"):
    people = []
    for account in accounts:
        if not account.website:
            continue
        payload = find_similar_people(api_client, employer_website=account.website, role=target_role)
        data = payload.to_dict() if hasattr(payload, "to_dict") else payload
        for item in data.get("results", []) or data.get("people", []) or []:
            people.append(
                ProspectPerson(
                    account_domain=normalize_domain(account.website),
                    full_name=item.get("full_name"),
                    role=item.get("role"),
                    work_email=item.get("work_email"),
                    x_handle=item.get("x_handle"),
                )
            )
    return people

That is why people discovery should follow account logic. You want relevance. Not decorative personalization.

Loop 4: Enrich and monitor

If your workflow has no timing layer, it is not agentic lead generation. It is a nicer spreadsheet.

Enrich the account

Use these NinjaPear endpoints:

• Company Details for context
• Employee Count for fit and segmentation
• Company Funding for capital signal
• Company Monitor and Company Updates for recent public changes

Endpoint map:

Wrappers:

def get_company_details(api_client, website: str):
    api = ninjapear.CompanyAPIApi(api_client)
    return api.get_company_details(website=website)


def get_employee_count(api_client, website: str):
    api = ninjapear.CompanyAPIApi(api_client)
    return api.get_employee_count(website=website)


def get_company_updates(api_client, website: str):
    api = ninjapear.CompanyAPIApi(api_client)
    return api.get_company_updates(website=website)

Sample Company Details shape:

{
  "name": "Stripe",
  "website": "https://stripe.com",
  "description": "Financial infrastructure platform for businesses.",
  "industry": 40205020,
  "specialties": ["payments", "billing", "fraud prevention"],
  "x_profile": "https://x.com/stripe"
}

Sample Employee Count shape:

{
  "website": "https://stripe.com",
  "employee_count": 8000
}

Sample Company Funding shape:

{
  "company_name": "Stripe",
  "funding_rounds": [
    {
      "round_type": "Series H",
      "announced_date": "2023-03-15",
      "money_raised": 6500000000,
      "lead_investors": ["Andreessen Horowitz"]
    }
  ]
}

Add company changes

This is where the system gets its timing.

NinjaPear’s update model covers:

• blog posts
• X posts
• meaningful website changes

And the output can be consumed as RSS. That part matters because it means you can push it into Slack, a CRM worker, or your own queue without much glue.

Sample Company Updates response shape:

{
  "updates": [
    {
      "title": "New Checkout Experience for Global Payments",
      "category": "blog",
      "summary": "Stripe announced a new checkout experience focused on international merchants.",
      "link": "https://stripe.com/blog/new-checkout",
      "published_at": "2026-02-27T10:00:00Z"
    },
    {
      "title": "Pricing page updated, new Enterprise tier added",
      "category": "website update",
      "summary": "A new enterprise pricing tier was detected on the public pricing page.",
      "link": "https://stripe.com/pricing",
      "published_at": "2026-02-27T07:00:00Z"
    },
    {
      "title": "We just launched Stripe Billing v3",
      "category": "x",
      "summary": "Product launch announcement on X.",
      "link": "https://x.com/stripe/status/1839200000000000000",
      "published_at": "2026-02-26T14:30:00Z"
    }
  ]
}

The published pricing examples for monitoring are a good sanity check:

That is enough to test timing-based lead generation without turning it into a big budget exercise.

Set up monitoring

Keep the wrapper thin:

def create_monitor_feed(api_client, websites: list[str], frequency: str = "daily"):
    api = ninjapear.CompanyAPIApi(api_client)
    return api.create_monitor_feed({"targets": websites, "frequency": frequency})

Sample monitor response shape:

{
  "rss_feed_url": "https://nubela.co/api/v1/monitor/feed/demo-stripe.xml",
  "targets": [
    "https://stripe.com",
    "https://shopify.com"
  ],
  "frequency": "daily"
}

Build a score

Start with a plain scoring function.

def score_account(is_competitor_customer: bool, employee_count: int | None, recent_updates: int, role_match: bool) -> float:
    score = 0.0
    if is_competitor_customer:
        score += 40
    if employee_count and 50 <= employee_count <= 2000:
        score += 20
    score += min(recent_updates * 10, 20)
    if role_match:
        score += 20
    return score

Signal table:

Optional person score:

def score_person(person: ProspectPerson, account: ProspectAccount) -> float:
    score = 0.0
    if person.role and any(k in person.role.lower() for k in ['revenue', 'sales', 'marketing', 'growth', 'operations']):
        score += 40
    if person.work_email:
        score += 20
    if person.x_handle:
        score += 10
    score += min(account.score / 3, 30)
    return round(score, 2)

That is basically the timing argument in one comment.

Wire the PydanticAI agent

You do not need a full PydanticAI tutorial here. You need enough to keep orchestration typed and in one place.

Typed output model:

from pydantic import BaseModel

class LeadGenResult(BaseModel):
    accounts: list[ProspectAccount]
    people: list[ProspectPerson]
    summary: str

Agent initialization:

from pydantic_ai import Agent
from pydantic_ai.models.openrouter import OpenRouterModel
from pydantic_ai.providers.openrouter import OpenRouterProvider

model = OpenRouterModel(
    settings.openrouter_model,
    provider=OpenRouterProvider(api_key=settings.openrouter_api_key),
)

agent = Agent(
    model,
    output_type=LeadGenResult,
    system_prompt="Build an agentic lead generation queue using NinjaPear data and return typed results only.",
)

Tool-wrapped workflow:

from pydantic_ai import RunContext

@agent.tool
async def build_queue(ctx: RunContext[AgentDeps], seeds: list[str], target_role: str = "Head of Revenue Operations") -> dict:
    with make_client(ctx.deps.settings.ninjapear_api_key) as api_client:
        result = run_pipeline(api_client, seeds=seeds, target_role=target_role)
    return result.model_dump()

That is enough structure for a useful agent.

Add NinjaPear tools

This is the bridge between docs and working code.

I would put the wrappers in app/tools/ninjapear.py.

Required wrappers:

• get_customer_listing
• get_competitors
• get_company_details
• get_employee_count
• get_company_updates
• get_company_funding
• get_person_profile
• find_similar_people
• create_monitor_feed

Rule of thumb:

• NinjaPear code should be real
• non-NinjaPear helpers should be mocked explicitly

Model table:

Mocked helpers:

def verify_email(email: str) -> dict:
    return {
        "email": email,
        "is_valid": email.endswith("@example.com") is False,
        "provider": "mock",
    }


def send_email(to: str, subject: str, body: str) -> dict:
    return {
        "to": to,
        "subject": subject,
        "status": "mocked-not-sent",
    }

Be explicit about mocks. It keeps the system honest.

Build the full GitHub project

The repo for this guide should live at the root, not inside a wrapper folder. The README.md should also link back to the article.

Repo tree:

agentic-lead-generation/
├── README.md
├── .env.example
├── requirements.txt
├── app/
│   ├── config.py
│   ├── models.py
│   ├── main.py
│   ├── scoring.py
│   ├── tools/
│   │   ├── ninjapear.py
│   │   └── mock_email.py
│   └── workflows/
│       └── pipeline.py
└── examples/
    └── run_demo.py

A few short excerpts.

config.py

class Settings(BaseModel):
    ninjapear_api_key: str = Field(..., alias='NINJAPEAR_API_KEY')
    openrouter_api_key: str = Field(..., alias='OPENROUTER_API_KEY')
    openrouter_model: str = Field(default='anthropic/claude-sonnet-4-5', alias='OPENROUTER_MODEL')

models.py

class ProspectAccount(BaseModel):
    source_company: str
    relationship_type: Literal['customer', 'investor', 'partner_platform', 'competitor']
    website: str | None = None
    normalized_domain: str | None = None
    name: str
    score: float = 0.0

tools/ninjapear.py

def make_client(api_key: str):
    configuration = ninjapear.Configuration(host='https://nubela.co', access_token=api_key)
    return ninjapear.ApiClient(configuration)

scoring.py

def score_account(is_competitor_customer: bool, employee_count: int | None, recent_updates: int, role_match: bool) -> float:
    score = 0.0
    if is_competitor_customer:
        score += 40

workflows/pipeline.py

def run_pipeline(api_client, seeds: list[str], target_role: str = 'Head of Revenue Operations') -> LeadGenResult:
    accounts = pull_competitor_customers(api_client, seeds)
    competitors = expand_competitors(api_client, seeds, max_depth=1)

main.py

result = agent.run_sync(
    'Build the lead generation queue for Stripe and Shopify competitors.',
    deps=AgentDeps(settings=settings)
)

examples/run_demo.py

result = run_pipeline(
    api_client,
    seeds=['https://stripe.com', 'https://shopify.com'],
    target_role='Head of Revenue Operations',
)

That repo is the lead magnet here. That is the asset people actually want.

Run an end-to-end example

Now run the workflow from the perspective of a founder using Stripe and Shopify as the wedge.

Input:

seeds = ["https://stripe.com", "https://shopify.com"]
target_role = "Head of Revenue Operations"

Runnable demo shape:

from app.config import Settings
from app.tools.ninjapear import make_client
from app.workflows.pipeline import run_pipeline


def main():
    settings = Settings.from_env()
    with make_client(settings.ninjapear_api_key) as api_client:
        result = run_pipeline(
            api_client,
            seeds=['https://stripe.com', 'https://shopify.com'],
            target_role='Head of Revenue Operations',
        )
    print(result.model_dump_json(indent=2))

What happens:

1. Pull customer lists for Stripe and Shopify.
2. Expand the competitor graph by one layer.
3. Re-run customer pull on selected adjacent competitors.
4. Keep top accounts.
5. Find similar people at those accounts.
6. Enrich with headcount and updates.
7. Score and rank.

Representative intermediate account output after Loop 1:

[
  {
    "source_company": "https://stripe.com",
    "relationship_type": "customer",
    "name": "Apple",
    "website": "https://www.apple.com",
    "normalized_domain": "apple.com",
    "description": "Apple Inc. designs, manufactures, and markets smartphones, personal computers, tablets, wearables, and accessories worldwide.",
    "score": 0
  },
  {
    "source_company": "https://shopify.com",
    "relationship_type": "customer",
    "name": "Toyota",
    "website": "https://toyota.com",
    "normalized_domain": "toyota.com",
    "description": "Global automotive manufacturer.",
    "score": 0
  }
]

Representative intermediate people output after Loop 3:

[
  {
    "account_domain": "shopify.com",
    "full_name": "Jane Doe",
    "role": "Head of Revenue Operations",
    "work_email": "[email protected]",
    "x_handle": "janedoe",
    "score": 0
  }
]

Representative final JSON shape:

{
  "accounts": [
    {
      "website": "https://example.com",
      "source_company": "https://stripe.com",
      "relationship_type": "customer",
      "score": 78
    }
  ],
  "people": [
    {
      "full_name": "Jane Doe",
      "role": "Head of Revenue Operations",
      "account_domain": "example.com"
    }
  ],
  "summary": "Found 14 high-fit accounts and 9 likely buyer profiles from 2 seed competitors."
}

If you want to generate an outreach task after that, fine. Just keep email sending mocked until the queue quality is real.

Use the NinjaPear Skill

If you already use an AI coding agent, install the NinjaPear Skill first.

It teaches the agent the boring parts that people usually get wrong:

• auth setup
• endpoint selection with cost awareness
• Python and JavaScript SDK usage
• pagination handling
• rate limit handling
• error handling for 401, 403, 404, 429, 500, 503
• timeout configuration

Install commands:

npx skills add NinjaPear/ninjapear-skill -a claude-code
npx skills add NinjaPear/ninjapear-skill -a codex
npx skills add NinjaPear/ninjapear-skill -a opencode

That is useful here because the whole point of this guide is to build an agentic lead generation system that actually ships.

Most lead generation articles still explain funnels to people who need systems.

This is the simpler frame I would use instead:

1. Who is already buying in the category?
2. Which adjacent accounts should I care about next?
3. Which humans are worth routing to?
4. Why is now the right moment?

If your stack cannot answer all four, your agentic lead generation setup is mostly branding.

So the next step is simple. Clone the repo, plug in your API keys, and run it against two competitors you already know. Start with Stripe and Shopify if you want the exact wedge from this guide.

And if you are building with Claude Code, Codex, or Opencode, install the NinjaPear Skill before you touch the code. It will save you time on auth, pagination, and endpoint selection.

If you searched true people search because you want the fast answer, here it is: yes, it works for quick lookups, and no, I would not trust it for anything important. The useful part is real. The privacy tradeoff is real too.

TL;DR

My blunt take

TruePeopleSearch is useful.

That is the first thing to say. If you need to identify a spam caller, check an old address trail, or find someone from partial info, it can be faster than the prettier sites.

It is also the kind of tool that changes character when you search yourself. Then it stops being a lookup tool and starts feeling like a public directory of things most people assumed were harder to find.

That is my verdict on true people search in one sentence: good for casual lookups, bad as a source of truth, and worth opting out of if your own record is there.

The one-line verdict

• Use it for fast, casual, one-off lookups.
• Do not trust it for high-stakes verification.
• Do not use it for employment, tenant, or compliance-sensitive screening.
• If your profile is on it, remove it now.

What TruePeopleSearch gives you for free

This part is straightforward.

The official Google Play listing says TruePeopleSearch is a free people search service with updated records on nearly every adult in the US. It says you can get full address histories, phone numbers, email addresses, relatives, friends, associates, property information, and more.

In practical terms, that means:

• name search
• reverse phone lookup
• reverse address lookup
• current and past addresses
• phone numbers
• relatives and associates
• possible email addresses
• possible property information
• possible business listings

That is why people use it. Not because it is elegant. Because it is useful in the narrow way these tools are useful.

If your problem is “who keeps calling me from this number,” it can help.

If your problem is “I need a reliable answer for a decision that matters,” it cannot.

What “100% free” means

The best explanation comes from the app listing itself:

That is honest enough.

The searches are free. The experience is still monetized. You are not paying with a card, but you are absolutely moving through an ad-supported funnel.

This is why I do not buy the phrase “100% free” at face value. It is true in the narrow sense. It is incomplete in the practical sense.

Scorecard: TruePeopleSearch vs alternatives

I do not care much about who has the nicest homepage. I care about whether a tool gives me useful information with minimal nonsense.

My rubric

• Freshness: whether moved addresses and changed numbers seem to be reflected.
• Richness: how much you get before a paywall.
• UX clarity: whether you can get where you need to go without sidestepping ads.
• Privacy posture: whether opt-out is understandable and whether re-checking is clearly necessary.
• Trustworthiness: whether the site feels like it is helping you or steering you.

That last one matters.

People-search sites already start from a trust deficit. A bad interface makes it worse.

The privacy tradeoff is the product

This is the center of the whole thing.

TruePeopleSearch is useful because it aggregates details people do not expect to be aggregated so cleanly. Current and past addresses. Phone numbers. Relatives. Associates. Sometimes property context.

That is the feature.

It is also the reason people search themselves once and decide they want out.

Incogni’s 2025 removal guide says removals usually work within 24 to 72 hours, but also says listings may reappear as public records refresh. That caveat matters more than the initial removal flow.

It means removal is not really an event. It is maintenance.

What users are upset about

People are not upset because the font is bad.

They are upset because their address is online.

And the category-level fear is not hard to find on X either:

Your full name, home city, phone number, and relatives are on at least 47 websites right now. Free to view. Free to download. Free to use against you. 🧵 Here are the exact steps to DELETE YOUR DIGITAL FOOTPRINT

— Kanika (@KanikaBK) Mon Apr 13 17:32:02 +0000 2026

That is enough to explain the economics.

The lookup is free because the data is visible enough to make the site useful, and the site is useful enough to attract attention and ad clicks.

How the TruePeopleSearch opt-out works

The removal flow is not technically hard.

It is just annoying in the specific ways that data-broker opt-outs are annoying.

Core flow:

1. Go to https://www.truepeoplesearch.com/removal
2. Enter your email, accept the terms, complete CAPTCHA
3. Search by full name, city, and state
4. Find the right listing and open details
5. Scroll to Remove This Record
6. Confirm by email
7. Re-check after the waiting window

Incogni says this process takes 5 to 10 minutes and usually clears within 24 to 72 hours if you complete the email confirmation.

I also hit a Cloudflare block trying to access the removal page during testing.

That is worth mentioning because it adds friction right at the start.

Friction points

These are the things that actually waste time:

• common names create multiple candidate records
• confirmation emails may land in spam
• session expiry can happen during the process
• multiple records need separate removals
• listings may come back when public records refresh
• access can fail before you even start

This is why I do not think of opt-out as a button. I think of it as a queue of small tasks.

A better removal procedure

If you want this to stick as well as it can, use a system.

1. Use a dedicated email inbox for removals.
2. Search current and past cities and states.
3. Log every matching listing.
4. Confirm each email immediately.
5. Re-check after 72 hours.
6. Re-check again after 30 days.
7. Put a 90-day reminder on your calendar.
8. Repeat the process on adjacent brokers.

That sounds boring because it is boring.

It also works better than improvising.

Here is a basic tracker layout:

Alternatives by job

Most of the internet writes “alternatives” like an affiliate spreadsheet. That is not helpful.

The only useful way to compare these tools is by job.

FastPeopleSearch vs TruePeopleSearch

These two are very close.

Both are good at:

• quick name lookups
• reverse phone checks
• showing more than you expected for free

Both are bad at:

• trust-building interface design
• clear privacy posture
• making opt-out feel like part of the product instead of a legal obligation

If TruePeopleSearch does not give me what I want, FastPeopleSearch is the next tab.

That is the relationship.

Whitepages vs TruePeopleSearch

This one is simpler.

TruePeopleSearch usually shows more for free. Whitepages is cleaner.

That is the trade.

If I want a free hit, I start with TruePeopleSearch.

If I want a site that feels less chaotic, Whitepages is better.

Spokeo vs TruePeopleSearch

Spokeo makes more sense if you are willing to pay for stitched reports.

It makes less sense if all you want is a fast reverse phone lookup.

So no, Spokeo is not just “better.”

It is better for a different kind of user.

When NinjaPear fits instead

I want to be precise here.

If you are trying to find someone’s home address or personal phone number, NinjaPear is the wrong tool.

If you are trying to research a company executive, enrich an account, identify customers of a business, or monitor company changes, that is where NinjaPear fits.

This is not the same category.

Relevant product details from public NinjaPear materials:

• Customer Listing API maps customers, partners, and investors.
• NinjaPear says employee profiles are publicly sourced.
• Its homepage says Company Details, Employee Count, and Company Updates cost 2 credits per call each.
• It explicitly says it does not scrape the major professional social network for these endpoints.

That is the distinction that matters.

TruePeopleSearch is consumer people lookup.

NinjaPear is professional and company intelligence.

Who should use TruePeopleSearch

Good fit

• someone checking a spam caller
• someone doing a one-off lookup
• someone checking whether an old address still ties to a person
• someone trying to reconnect with an old friend from partial info

Bad fit

• hiring teams
• tenant screening
• compliance-sensitive work
• journalism or investigations that need confidence
• anyone treating “free” as a synonym for “safe” or “complete”

If the decision matters, this category is too messy to be the source of truth.

That is the practical rule.

The bigger lesson

Free people-search engines are selling a tradeoff.

You are not paying cash for the search. Fine.

But the product still needs a business model, and the business model depends on two things:

1. enough useful personal data to make the lookup worth doing
2. enough traffic and monetization to keep the machine running

That is not a conspiracy theory. It is just the shape of the product.

This is why the same tool can feel useful and invasive at the same time.

It is both.

FAQ

Is TruePeopleSearch legit?

Yes. It is a real service with a website and Android app. That does not make it reliable enough for serious verification.

Is TruePeopleSearch really free?

Yes, according to its own listing. It also says the app contains ads and sponsored links that can send users to paid services.

Is TruePeopleSearch safe to use?

For casual browsing, usually. For serious decisions, no.

How do I remove my info from TruePeopleSearch?

Go to truepeoplesearch.com/removal, search your record, open the listing, click Remove This Record, and confirm by email.

Can my info come back after removal?

Yes. Incogni says records may reappear as public records refresh.

Is there a TruePeopleSearch app?

Yes. There is an Android app on Google Play.

What are the best alternatives?

For consumer lookups: FastPeopleSearch, Whitepages, and Spokeo. For professional or company intelligence: use a purpose-built B2B tool.

Is NinjaPear an alternative to TruePeopleSearch?

Not for consumer people search. Yes for professional and company intelligence work.

Final verdict

Need a quick free lookup? It can help.

Need accuracy you can rely on? No.

Found your own record? Remove it now.

Need B2B professional or company intelligence? Use a tool built for that job instead.

If you do one thing after reading this, do not overthink it. Search yourself on TruePeopleSearch. If your record is there, start the opt-out, log it, and put a reminder on your calendar.

Sources

• TruePeopleSearch Google Play listing: https://play.google.com/store/apps/details?id=com.freedataservices.truepeoplesearch&hl=en_US
• TruePeopleSearch removal page: https://www.truepeoplesearch.com/removal
• Incogni TruePeopleSearch opt-out guide: https://blog.incogni.com/true-people-search-removal/
• Reddit privacy thread: https://www.reddit.com/r/privacy/comments/1at4xeh/how_do_you_get_your_data_off_true_people_search/
• Reddit comment permalink: https://www.reddit.com/r/privacy/comments/1at4xeh/how_do_you_get_your_data_off_true_people_search/kt8vjgq/
• X post by Kanika: https://x.com/KanikaBK/status/2043744028991336935
• NinjaPear overview: https://nubela.co
• NinjaPear Customer Listing API: https://nubela.co/customers
• Free download: https://f000.backblazeb2.com/file/agent-pub-filestore/_bundle-ba713bf6.zip

Most competitor research tools lists are useless because they mash five different jobs into one fake category. If you only need keyword overlap, buy an SEO tool. If you need ongoing monitoring, buy a monitor. If you need account-level company intelligence, buy something built for company data. The expensive mistake is buying a bloated suite because the demo looked smart.

When I was running FluxoMetric, I learned the hard way that "all-in-one" usually means "half-useful across six tabs." I burned ~${"4K"}/mo on tools that made me feel informed while I was still blind to the part that mattered: what changed, who moved, and whether the move affected my market.

TL;DR

Here is the fast answer on competitor research tools.

That last row is the whole point. There is no single best competitor research tool because this is not one category. It is five jobs wearing one trench coat.

What most lists get wrong

Most lists call everything from Ahrefs to Crayon to Similarweb a competitor research tool. That is lazy. It is also how buyers end up paying for the wrong thing.

These are the actual buckets:

1. Keyword overlap: who ranks where, who owns what terms, where your content gaps are.
2. PPC intel: who bids on what, what ads they keep running, where paid competition is heating up.
3. Traffic intel: directional traffic, channel mix, geography, audience share.
4. Ongoing monitoring: pricing changes, new pages, launch posts, messaging shifts.
5. Company intelligence: customers, partners, investors, hiring moves, competitive maps.

A CEO shopping for competitor research tools usually does not need one platform. They need one answer per job.

This is where a lot of software buying goes wrong. Somebody buys a giant suite, then the team uses 12% of it, then six months later everyone says they need "better adoption." No. They needed a tighter brief.

The short answer

Here is the shortest honest buying guide I can give you.

Best for keyword overlap

Ahrefs is my pick if you care about depth, backlink context, and content gap work.

Semrush is the better fit if you want a broader suite and are willing to tolerate more sprawl.

Ahrefs public pricing is unusually clear. At the time of writing, it lists Starter at $29/mo, Lite at $129/mo, Standard at $249/mo, and Advanced at $449/mo. That makes it one of the easier tools to budget.

Semrush also publishes pricing, though the product packaging has gotten more layered over time. Its SEO plans show Pro at $139/mo, with lower annualized rates when billed yearly, then Guru and Business above that.

Best for PPC intel

SpyFu.

Not because it is magical. Because the job is narrow and the price is sane. SpyFu's pricing page starts at $39/mo on Basic, with Pro + AI higher and Team above that. If your real job is ad history and keyword reconnaissance, that is enough.

Best for traffic intel

Similarweb, but only if you actually need traffic intel.

Most CEOs do not. They need cleaner decisions, not prettier traffic charts. Similarweb has public packages, but the useful stuff quickly moves you into bigger plans. Public entry points vary by package, with some self-serve offers and a lot of sales-led pricing.

Best for monitoring

Visualping for page-level monitoring.

Visualping is good at one thing: watch a page and tell me it changed. Public pricing starts at $10/mo for personal use, with bigger business tiers above that.

Best for company intelligence

NinjaPear, if your question is not "who outranks us?" but "who buys from them, what changed at the company, and where are the useful account signals?"

That is a different job from SEO. It should be a different tool.

Types of competitor research

If you skip this section, you are more likely to buy the wrong product.

Keyword overlap

This is classic search work:

• who ranks for the same terms
• where you are losing share
• what content gaps matter
• what backlinks or SERP features they own

Ahrefs and Semrush are built for this. Everything else is filling in.

PPC overlap

Different job.

You want to know:

• which keywords competitors appear on
• which ad copy they keep reusing
• what landing pages keep showing up
• where paid competition is getting hotter

SpyFu is the budget specialist here. Google Ads Auction Insights is still better for your own account truth, but not for broader market snooping.

Traffic intel

Traffic intel is estimation. That does not make it useless. It does mean you should stop treating it like audited financials.

Use it for:

• relative comparisons
• directional trends
• share-of-market discussions
• channel mix sanity checks

Do not use it to argue over whether a site got exactly 1.7M or 2.1M visits.

Ongoing monitoring

This is the "what changed since last week?" layer.

You care about:

• pricing page edits
• new feature pages
• fresh blog posts
• social posts
• message changes
• launches and removals

Visualping handles the page-watch piece well. Broader monitoring needs broader collection and better filtering.

Company intelligence

This is the layer most competitor research tools roundups barely understand.

You care about:

• customers
• partners and platforms
• investors
• hiring shifts
• leadership changes
• account-level timing signals

SEO tools are weak here. They tell you who ranks next to you. They do not tell you who buys from your competitor or when a prospect account just changed its stack.

The scorecard

I care about a few things when I test these tools:

• Does the data help me make a decision this week?
• How many clicks until the useful part?
• Is the price sane for a small team?
• Does the monitoring create signal or noise?
• Can I export or pipe data into something else?
• Is this useful to a CEO, not just a specialist?

Scoring criteria

Tools compared

The enterprise CI tools have a recurring problem. If nobody maintains the system, the system becomes furniture.

Keyword overlap tools

If the job is search overlap, do not talk yourself into buying a generic CI suite.

Ahrefs

Ahrefs is still the cleanest tool here if the work is:

• backlink inspection
• content gap work
• SERP analysis
• SEO operator workflows

I like that Ahrefs pricing is public and readable. I also like that the product is still opinionated. It feels built by people who expect you to do actual SEO, not admire a dashboard.

What I like:

• strong backlink context
• clean workflow for content gap work
• good depth for people who live in SEO every week

What I do not like:

• expensive if you use it casually
• easier to justify for operators than founders
• not the tool I would buy for broad company intelligence

If you log in twice a month, it is probably too much tool.

Semrush

Semrush is broader.

That can be good. It can also mean you are paying for surface area you will never touch.

What I like:

• broader workflow coverage
• decent overlap and competitive research features
• good fit if one team wants one account for several adjacent jobs

What I do not like:

• sprawl
• too many tabs for buyers with a narrow brief
• easy to overbuy if you only need one core motion

Semrush makes sense when one team is going to live in it. It makes less sense when a founder wants one sharp answer once a week.

SpyFu

SpyFu is better than its prestige suggests.

That is not the same as saying it is better than everything else. It means it knows what lane it is in.

For $39/mo, you get a cheap way to inspect competitor ad history, keyword overlap, and basic domain comparisons. For a lot of PPC teams, that is enough.

That is about right. Use SpyFu as cheap reconnaissance. Do not use it as forensic truth.

Traffic intel tools

This is the part of the market where the charts get nicer as the certainty gets worse.

Similarweb

Similarweb is the best-known traffic intel product because it is easy to explain to an executive team.

What it does well:

• directional traffic comparisons
• channel views
• geography splits
• market-level benchmarking

What it does poorly:

• stopping buyers from treating estimates as truth
• stopping teams from overbuying

That quote is about PPC tools, but the discipline carries over. Estimated market data is still estimated market data.

I use Similarweb as directional evidence. I do not use it as scripture.

Most CEOs do not need Similarweb. They need a better answer to "is this market moving?" and "where are we being outflanked?" If you cannot name the decision the tool changes, skip it.

Semrush traffic tools

If you already pay for Semrush, its traffic and competitive research features are often enough.

Not as deep as Similarweb. Usually enough for:

• rough benchmarking
• channel mix glimpses
• quick market checks

If you are running a smaller company and somebody is pushing Similarweb by default, I would ask what decision requires it. Usually the answer gets vague fast.

SparkToro

SparkToro is not a traffic estimation platform. It is an audience discovery tool.

That distinction matters.

Sometimes the real question is not "how much traffic do they get?" It is "where does this audience pay attention?"

SparkToro pricing starts at $38/mo with a free tier above that. Good fit for:

• source discovery
• audience research
• creator / publication / podcast mapping

Wrong fit if you want a Similarweb clone.

Monitoring tools

Monitoring is where a lot of teams either save themselves or sign up for fresh inbox noise.

Visualping

Visualping is a clean answer for page-level monitoring.

You point it at:

• pricing pages
• feature pages
• comparison pages
• docs pages
• policy pages

and it tells you what changed.

That is useful. It is also very easy to configure badly.

That is the failure mode. Pixel diffs without context become noise.

My rule is simple: monitor fewer pages, but monitor pages that can change a deal.

Owler

Owler is fine for lightweight company alerts.

That sounds faint praise because it is. But faint praise is appropriate here.

If you want:

• basic company following
• simple alerts
• easier setup than enterprise CI software

it can work. It is not deep company intelligence. It is not relationship mapping. It is not what I would buy for a team that needs account-level precision.

Crayon / Klue

I am grouping these together because they solve a similar org problem:

• product marketing
• sales enablement
• battlecards
• CI distribution inside a team

This is the part where a lot of software buying becomes theater.

If nobody updates the battlecards, you did not buy intelligence software. You bought an expensive graveyard.

That is the problem statement in one paragraph.

NinjaPear

This is where I need to be precise.

NinjaPear is not trying to replace Ahrefs. It is not pretending to be a generic SEO suite.

It is useful when the monitoring job spans:

• blog posts
• X posts
• meaningful website changes
• customer and competitor context

That last part matters. A page diff without business context is just motion. Context is what makes the motion useful.

The first mention that fits this section is NinjaPear Company Monitor. It watches blogs, websites, and social posts, then tries to filter down to changes that matter.

Company intelligence tools

This is where most lists flatten the category and lose the plot.

NinjaPear

If I care about business questions, I want business data.

The useful pieces on NinjaPear are:

• company updates
• customer lists
• competitor identification
• employee profiles
• usage-based API access

The pricing page is sparse, but the public credit table is refreshingly concrete. It lists 2 credits for Company Details, 2 credits for Employee Count, and 1 credit + 2 credits per customer returned for Customer Listing. That is a lot more useful than "contact sales."

This is the point where SEO-only competitor research starts looking incomplete.

If you know who buys from a competitor, you can:

• build a target account list
• compare ecosystems
• find whitespace
• understand where the market already trusts similar vendors

That is closer to how CEOs and sales leaders actually make decisions.

Owler

Owler gives you lightweight awareness.

That is not nothing. It is just not the same as relationship intelligence, customer mapping, or fresh account signals.

Similarweb and others

Similarweb can tell you a lot about audience and traffic patterns. It cannot tell you the relationship map behind the market.

That distinction matters.

Traffic intel answers: How visible are they?

Company intelligence answers: How are they embedded in the market?

Different questions. Different tools.

Free tools that still help

Not every stack needs to start with a $400 tab.

Free SEO checks

Still useful:

• Wappalyzer extension for quick tech stack checks
• Google search operators for rough overlap checks
• free traffic checkers for direction, not truth
• limited free SEO tool tiers

Wappalyzer has a free tier, then jumps to paid plans fast. Its pricing page lists Pro at $250/mo and Business at $450/mo. That makes the extension much more useful than the broader paid product for most small teams.

Free monitoring

Visualping's free checks can cover a handful of critical pages if you are disciplined.

Track:

• one pricing page
• one product page
• one compare page
• one blog or changelog feed

Not 200 pages because it felt productive during setup.

Free company research

Public company pages, news searches, press releases, funding pages, and free developer utilities still do useful work.

If you can answer the question with public web plus a browser extension, do that first.

Tool stacks by team

This is where I see the most wasted money.

CEO at a small company

Buy:

• one SEO tool, Ahrefs or Semrush
• one monitoring tool, Visualping

Do not buy:

• Ahrefs + Semrush + Similarweb + an enterprise CI platform

You do not need three overlapping suites to feel serious.

Growth marketing team

Buy:

• Semrush or Ahrefs
• maybe SpyFu if PPC matters
• add monitoring only if somebody actually owns it

If nobody owns it, the alerts become wallpaper.

Product marketing / CI team

Buy:

• monitoring
• battlecard workflow only if the team is real, not aspirational
• company intelligence if you need context across accounts and competitors

This is where broader CI tooling starts to make sense. It is also where shelfware starts.

B2B sales team

SEO tools alone are half-blind here.

You need:

• company changes
• relationship mapping
• customer lists
• account-level signals

This is why SEO tooling alone disappoints sales leaders. It answers the wrong question.

Where NinjaPear fits

I do not like vendor writing that pretends one tool replaces everything. So here is the narrower, honest version.

What it is good at

NinjaPear is good at:

• company updates
• competitor mapping
• customer lists
• relationship intelligence
• B2B account research
• API-first workflows

That is the lane.

What it is not

It is not a replacement for Ahrefs or Semrush when the job is:

• backlink analysis
• keyword clustering
• content gap work
• SERP-level SEO analysis

That is not modesty. It is just category hygiene.

FAQ

What is the best competitor research tool overall?

There is no single best tool overall. For keyword overlap, buy Ahrefs or Semrush. For PPC, buy SpyFu. For traffic intel, buy Similarweb if you truly need it. For business relationship intelligence, buy NinjaPear.

What are the best free competitor research tools?

Wappalyzer's free extension, Visualping's free checks, search operators, and free traffic checker tools are the best starting point. They will not replace paid tools, but they can stop you from buying blindly.

What is the best tool for keyword overlap?

Ahrefs gets my vote for depth. Semrush if you want broader workflow coverage.

What is the best tool for ongoing competitor monitoring?

Visualping for page-level change detection. If you want broader company-level monitoring across sites, blogs, and X, NinjaPear is stronger.

Is Similarweb accurate enough to trust?

Directionally, yes. Literally, no. Use it for trend direction and peer comparison. Not audited truth.

SpyFu vs Semrush, which is better for PPC?

For narrow PPC competitor intel, SpyFu is better value. For a broader marketing suite that also includes PPC-adjacent workflows, Semrush is broader but more expensive.

What is the best competitor research tool for CEOs?

For most CEOs, the best stack is one SEO tool plus one monitoring tool. Add company intelligence only if your market motion and deal timing actually require it.

Final verdict

Here is the blunt answer.

• For keyword overlap, buy Ahrefs or Semrush.
• For PPC intel, buy SpyFu.
• For traffic intel, buy Similarweb only if you actually need it.
• For ongoing monitoring, buy Visualping or a broader monitor if your team will use it.
• For business relationship intelligence, add NinjaPear.
• Do not buy a giant suite to solve a narrow problem.

That last line is the article.

"Competitor research tools" is mostly a fake category. Real buying decisions happen one job at a time.

If you want a practical next step, download the scorecard and fill it out before you buy anything. That exercise alone will usually kill one bad purchase.

If your real blind spot is company changes, customer overlap, and relationship mapping, then that is the point where an SEO tool stops being enough. That is where I would look at NinjaPear. If not, keep your stack smaller. Smaller stacks get used.

If you are using Claude Code (and not hating on Anthropic because of the recent nerf to their model), add the NinjaPear skill to Claude:

Bash

$ npx skills add NinjaPear/ninjapear-skill -a claude-code

And if you've started exploring Codex like I have:

Bash

npx skills add NinjaPear/ninjapear-skill -a codex

It's pretty cool. Once you have that added, the skill will give your coding agent knowledge on how to best work with NinjaPear correctly, including SDK integration, error/pagination/rate limit/timeout handling, as well as cost management!

In case you do not know yet, I'm an AI maximalist. And a lot of NinjaPear is driven by AI—much more than you think. When NinjaPear hits $1M ARR, and I'm sure it will in a few months' time, I'll show you what goes on behind the scenes of NinjaPear.

Ok, in a nutshell:

1. For integrators: Use the NinjaPear skill if you are integrating NinjaPear into your applications.
2. For users: Use the NinjaPear MCP if you want to work with NinjaPear's data inside your AI agent without writing code.
3. For non-AI maximalists: Use NinjaPear docs for AI agents, which you can link to or drag and drop into your AI agent chat.

Questions? Shoot me an email at hello@nubela.co!

I’ve signed the software bill before. That changes how you look at tools like Visualping. Here’s the short version: Visualping is good at watching pages. I’d use it for pricing pages, job boards, docs, policy pages, and some gated portals. I would not use it as my main competitive intelligence system. That is the mistake. Not the tool.

That quote is useful because it kills the lazy take. Visualping is not a toy. It can do real browser steps. The problem is that people buy a page monitor and expect it to think for them.

TL;DR

If you only need page alerts, Visualping is a sane buy. If you need company intel, it is the wrong layer.

Upfront: I’m a competitor

I lead GTM at NinjaPear. We sell Company Monitor. So yes, I’m biased.

I still think that bias is useful here.

I’ve spent real money on this category. When I was running FluxoMetric, I wasted ~$4K a month at one point on monitoring and enrichment tools that looked good in demos and created work in practice. More alerts. More tabs. More triage. Less signal.

So I’m not selling you neutrality. I’m giving you the version I’d want if I were the one approving the spend.

The 20-second verdict

Verdict: Visualping is good software. It is easy to set up, good on visual diffs, and more capable on dynamic pages than most people realize. My score is 3.1/5.

Use it for page alerts

Use Visualping for: - pricing pages - careers pages - docs and changelogs - policy and compliance pages - restocks and ticket drops - some authenticated dashboards

That is a real list. Not a consolation prize.

Skip it for market intel

Do not buy Visualping if what you actually mean is: “tell me what this company is doing.”

A page monitor can tell you a page changed. It does not automatically tell you whether the change matters, what it means, or how it connects to the rest of the company’s behavior.

That sounds like a small distinction. It isn’t.

What Visualping gets right

Setup is dead simple

This part is good.

The homepage still does the right thing. It shows the basic workflow fast: enter URL, click Go, choose what to track, pick frequency, send the alert. That matters because half the battle here is getting somebody to actually finish setup.

That is a better product story than the usual feature soup.

Visual diffs are human-friendly

A lot of monitoring tools are built for people who don’t mind selectors, HTML, and ugly text diffs.

Visualping is easier on normal humans.

That matters if the reviewer is a founder, PMM, RevOps lead, or analyst who wants to know what moved without reading DOM noise. Screenshot diffs are easier to scan than raw page churn. You see the change. Fast.

It handles tricky pages

Visualping can do more than static pages.

TechRadar specifically called out its “perform actions” feature for typing, clicking, and scrolling. Visualping’s own 2026 guide on password-protected pages also documents two approaches for gated content:

1. Chrome extension
2. Pre-actions with element selector

That means it can handle things like login flows, wait states, and pages that need a little browser behavior before the content appears.

That does not make it magic. It just makes it more capable than the average review admits.

Where it starts to suck

Change is not signal

This is the core problem.

A page monitor tells you something changed. It does not reliably tell you: - whether the change matters commercially - whether it was noise - whether the change connects to anything bigger - whether someone should act on it

Visualping clearly knows this. Their product and help docs lean hard into AI summaries, AI importance logic, and higher-end managed options.

Their own help article on Business vs Solutions says the Solutions tier includes AI concierge service, custom data structure and output, starter packs, image change interpretation, and upgraded models for better summaries.

That tells you what the real hard part is.

Not crawling pages. Interpreting them.

Noise becomes labor

The invoice is rarely the real cost.

The real cost is the person who has to read the alerts.

Who opens them? Who filters junk? Who decides what matters? Who keeps false positives from becoming background radiation?

That cost compounds fast.

That is the category in one paragraph.

The product can be fine. The labor model can still be wrong.

Website-only is a narrow lens

If your use case is “watch this page,” website-only is fine.

If your use case is “watch this company,” website-only is already incomplete.

Companies signal through: - website edits - new pages in sitemaps - blog posts - changelogs - X posts - hiring activity - positioning changes

Visualping covers one slice of that well. It does not cover the whole thing as one feed.

That is why I keep separating page monitoring from company monitoring. They are different jobs.

Pricing: the real trap

Free gets you hooked

Public references on Visualping’s free plan vary.

The Chrome Web Store listing says 62 checks/month free for the server service. TechRadar’s 2025 review says 150 checks/month and 5 pages on the free plan.

That inconsistency is not the point.

The point is that the free tier is for learning the product, not for pricing a workflow.

Business is where workflows start

TechRadar reported these public anchors in 2025: - $10/month for 1,000 checks and up to 25 pages - $50/month for 10,000 checks and up to 200 pages - $100/month for 20,000 checks and around 500 pages - $250/month for 50,000 checks and around 1,500 pages

Those are useful reference points. They are not the main story.

The main story is this: once you need Slack, Teams, Sheets, API, webhooks, shared workflows, and real team use, you are no longer buying a cheap side tool.

You are buying workflow software.

Visualping’s own help doc says Business plans are for professionals who want to integrate changes through API, Webhook, Google Sheets, Slack, or MS Teams. Their integrations page says integrations are available in all Business plans.

That is reasonable. I’m not complaining about it.

I’m saying buyers often budget for a utility and end up deploying a system.

Human review is the hidden cost

TechRadar also mentions paid support add-ons at $600/year, $1,200/year, and $3,000/year.

That is not even the part I care about most.

The hidden line item is analyst time.

If Visualping saves your team six hours a month, it is cheap.

If it creates eight hours a month of low-grade review work, it is not cheap anymore.

API and integrations reality

Integrations are solid

Visualping’s integrations page lists: - Slack - Microsoft Teams - Google Chat - Zapier - Google Sheets - Lindy.ai - n8n - Webhooks - Discord - API

That is a respectable list.

If your workflow ends in Slack or a webhook, Visualping is not weak here.

Programmatically, yes, it’s real

A lot of vendors say “API” and mean one thin endpoint.

Visualping looks more serious than that.

Their April 2026 API article shows actual API usage for: - creating jobs with POST https://job.api.visualping.io/v2/jobs - setting intervals in minutes like 5, 60, and 1440 - targeting a specific page region with xpath - adding preactions for click and type steps - configuring webhook notifications - pulling active jobs and change history - using AI importance definitions and summaries

That is enough for real operations work.

Once you get past ~30 monitors, the dashboard becomes the slow part. The API is how you stop doing repetitive setup by hand.

But integrations are not insight

A Slack alert about a page change is still a page change.

Moving the alert into Slack, Teams, Sheets, Zapier, or n8n does not improve the information. It improves routing.

Useful. Yes.

The same as insight. No.

Business-plan gating matters

Visualping’s help center is pretty clear here.

Business plans are for users who want to: - scale to more pages and higher frequency - collaborate in a shared dashboard - organize workspaces and labels - integrate with API, webhook, Sheets, Slack, and Teams

That matters because it changes the buying math.

If you’re a solo operator, Personal may be enough.

If you’re plugging alerts into an actual team workflow, you are already in Business territory.

Bot blocking, login walls, and edge cases

This is where most reviews get vague. I’m not going to do that.

Behind login walls, yes, with caveats

Visualping’s February 2026 guide on password-protected pages gives a clean table:

That is a good answer.

The extension captures your active browser session. In Device mode, checks run on your machine. In Server mode, it captures session data like cookies and local storage and sends them to Visualping’s servers for background checks.

That means: - 2FA and SSO: yes, with the extension - basic username/password: yes, with extension or pre-actions - messy SPA login flows: more likely with extension - expiring sessions: expect re-auth friction

That is real capability. Also real maintenance.

Bot detection, no, they are not pretending to be bulletproof

This is where I give them credit.

Their own guide says: “Some sites detect and block automated access.” The suggested workaround is the Chrome extension in Device mode, because it uses your real browser.

They also say pre-actions do not work with CAPTCHA-protected logins.

That is the right level of honesty.

Visualping is a monitoring tool. It is not a stealth anti-bot stack.

If your targets are consistently behind hostile bot defenses, this category gets harder fast.

Device mode vs server mode

This is the actual tradeoff.

Device mode is better when: - the site dislikes bots - auth is messy - you need your real session - you can tolerate checks only running while your machine and Chrome are alive

Server mode is better when: - you want background monitoring - sessions do not expire too fast - your laptop being closed should not stop the checks - the target site is not especially hostile

If your process depends on Device mode, somebody owns that browser session. Usually RevOps. Sometimes the founder. Sometimes an engineer who did not ask for this job.

Advanced use cases

Visualping is better than average when the workflow gets slightly weird.

Based on Visualping’s docs and TechRadar, the serious use cases include: - monitoring after click, type, scroll, or wait actions - watching specific elements instead of whole pages - monitoring password-protected pages - using custom AI importance definitions - sending alerts through webhooks - creating hundreds of monitors through the API - tracking keywords instead of every visual change

That is a real feature surface.

Still, advanced page monitoring is still page monitoring.

Is there an RSS feed?

I could find strong first-party evidence for: - email - Slack - Teams - Google Sheets - Google Chat - Discord - webhooks - Zapier - n8n - API

I could not find first-party evidence of a native RSS output for Visualping alerts.

Can you build an RSS-like workflow from a webhook?

Yes.

Is that the same as native RSS?

No.

That matters if your team wants feed-style monitoring instead of notification routing.

This is one place where NinjaPear Company Monitor is a different kind of product. It is built around a company-updates feed from the start.

My scorecard

That score is not a dunk. It is a fit score.

Visualping is good at a narrower job than many buyers want it to do.

Visualping vs Distill vs changedetection

Visualping vs Distill

Visualping is easier and more polished.

Distill tends to be better for people who want more control and do not mind more setup. Public pricing has also tended to look better for technical users who want faster intervals and more knobs per dollar.

My rough rule is simple: - give Visualping to a non-technical operator - give Distill to a power user who wants more control

Visualping vs changedetection

changedetection.io is the “I’d rather own the plumbing” option.

It is powerful. It is cheap. It is flexible. It is also work.

That is basically the tradeoff.

Visualping is easier. changedetection.io is better if your team is technical and cost-sensitive.

Visualping vs NinjaPear Monitor

This one is clean.

• Visualping = page monitoring
• NinjaPear Company Monitor = company updates across website, blog, X, and meaningful changes

If you want “did this page move?”, buy Visualping.

If you want “what is this company doing?”, buy a different class of tool.

That is why Company Monitor exists.

I got tired of teams forcing page diffs to do company-intel work.

What Reddit and X got right

Reddit on dynamic pages

The best Reddit quote I found is still the one about waiting for JS, clicking elements, and entering a zip code.

It’s short. It’s ugly. It’s believable.

And it proves the product can do more than static diffs.

Reddit on DIY alternatives

Reddit also gets the buyer split right.

Technical people compare Visualping with self-hosted options almost immediately. They should.

If Docker and selectors do not scare you, changedetection.io is worth a real look.

X on practical monitoring

I found one X post that captures a sane use case instead of pretending a page alert tool is a full intel system:

I use VisualPing to monitor changes on web pages. No fancy integration. No scraping. Just an alert when something changes. I use it for: - platform tweaks its docs - competitor updates pricing - goods price decrease 🤭 I get an email, and I’m already in the loop.

— Luca Restagno 🐢 blacktwist.app (@ikoichi) Jul 30, 2025

That is a good Visualping workflow. Narrow. Useful. No fantasy.

Screenshots and proof

Homepage hero

Integrations proof

Help-doc proof

Evidence table

Who should buy it

Buy Visualping if

Buy Visualping if: - you’re a solo operator or small team - you need simple page alerts - you care about visual diffs - your targets are mostly public web pages - you want something non-technical people can set up quickly - you may occasionally need login-wall monitoring and understand the caveats

Skip Visualping if

Skip it, or at least don’t make it your main system, if: - you need structured company intelligence - you need website + blog + X + new-page coverage together - you are trying to reduce analyst labor, not just detect movement - your targets are behind hostile bot defenses or CAPTCHA-heavy auth flows - you want a feed of meaningful company updates instead of screenshot diffs

My final take

Visualping is worth paying for when the job is page alerts.

That is my actual view. Not a hedge.

It is good software. It is easy to set up. It is more capable on dynamic and gated pages than a lot of people think. It also gets misbought all the time.

If your job is “alert me when this page changes,” Visualping is a reasonable answer.

If your job is “tell me what this company is doing,” it is the wrong layer.

That difference sounds small. It is not.

If you’re still deciding, do one boring exercise before you buy anything: list the pages you need to watch, the person who will review alerts, the action you’ll take when something changes, and whether those targets sit behind auth or bot friction. That will tell you very quickly whether you need a page monitor, a self-hosted setup, or a proper company-monitoring feed.

If you want to sanity-check the category without buying the wrong layer first, that sheet will do more for you than another ten feature-list reviews.

If I were buying a business intelligence platform in 2026, I’d start here: Power BI is still the safest default, Tableau is still best at visual analysis, Looker is still only worth it if you already have a real data team, Qlik is better than its market buzz, Sigma is the modern pick, and most companies are paying for complexity they will never use. The license is not the expensive part. The mess you create six months later is.

I like that quote because it gets to the point.

I’ve had to make this call with my own money. At FluxoMetric, I burned ~$4K a month on tools that looked great in demos and turned into chores in production. Later, at Meyer Growth Labs, I inherited BI setups that were already half-rotten. Nice dashboards. Bad models. Confused definitions. Nobody trusted the numbers.

That’s what this guide is about. Not features in isolation. Operating reality.

TL;DR