Some notes:

• You can run a demo API call that consume no credit, and return our favourite Mr. Bill Gates' pre-filled profile data.
• Or you can run an actual API call, register for an account here and get your API key to run it. It'll consume credits.

See the docs here.

Impressed by what you see? This is a demonstration of the Proxycurl API in action. There exists the official Professional Social Network API, as well as third-party Professional Social Network APIs like Proxycurl.

As the CEO of Proxycurl, and a coder myself, I've garnered a few years of experience dealing with Professional Social Network data. In this guide, I aim to equip you with a comprehensive understanding of Professional Social Network APIs, both official and 3rd-party alternatives. Expect a deep dive from both a technical and business perspective.

Types of Professional Social Network APIs

Professional Social Network APIs fall into two categories: the official Professional Social Network API and 3rd-party [Professional Social Network APIs](https://nubela.co/proxycurl/Professional Social Network).

To gain access to the official Professional Social Network API, you must be a Professional Social Network Partner. This means you, the developer, and your associated business will need to navigate through administrative hoops for several months in hopes of getting approved. One of the criteria for being approved as a Professional Social Network Partner is that you cannot be a competitor to Professional Social Network in any way. So, if you are in an industry like HR tech, building an application that might compete with an existing Professional Social Network product, you're out of luck.

As far as I'm aware, another requirement for being a Professional Social Network Partner is that you need to be paying five-digit monthly fees to Professional Social Network.

At the other end of the spectrum, we have 3rd-party Professional Social Network APIs. The world of third-party Professional Social Network APIs is like the wild west.

Some 3rd-party vendors, like [PhantomBuster](https://nubela.co/blog/proxycurl-api-vs-phantombusters-Professional Social Network-profile-scraper/), require you to supply your own Professional Social Network account(s). PhantomBuster is a great choice if you want to automate actions within your own Professional Social Network account and aren't scared of having your personal Professional Social Network account banned.

There are also vendors like People Data Labs (PDL), which have obtained bulk Professional Social Network data from various vendors and resell access to this combined Professional Social Network profile database. The data from such resellers often tend to be out-of-date.

Then, there are 3rd-party vendors that scrape Professional Social Network. There are variations in this category too. [Some of these scraping vendors](https://nubela.co/blog/what-you-should-know-now-that-mantheos-a-Professional Social Network-scraping-service-is-sued-by-Professional Social Network/) engage in fraudulent behavior, such as registering fake accounts and using private throwaway debit cards to sign up for free Sales Navigator trials, and then using such whitelisted accounts to scrape Professional Social Network at scale. Meanwhile, some vendors strictly work with [publicly accessible Professional Social Network profiles](https://nubela.co/blog/what-is-the-difference-between-Professional Social Network-public-profiles-vs-Professional Social Network-private-profiles-with-python-code-samples/).

The ramifications are significant. On one hand, companies that engage in fraud have been sued and shut down. On the other hand, companies that work exclusively with public Professional Social Network profiles operate within a [legally tested framework](https://nubela.co/blog/is-Professional Social Network-scraping-legal/) for compliance.

Here's a quick recap with the comparison table:

Interested in learning more about 3rd-party Professional Social Network APIs? We've compared [7 top Professional Social Network scraping tools](https://nubela.co/blog/reviewing-top-Professional Social Network-scraping-api-services/). You can read more about it.

Official Professional Social Network API

What Can You Do with the Official Professional Social Network API?

Professional Social Network is a formidable professional social network that serves as a treasure trove of data for professionals and job listings. This data is something that a recruitment tech startup or a sales automation product would love to integrate into their offerings. Professional Social Network recognizes its value and closed public access to their API in 2015. To access the official Professional Social Network API, you'll need to become a Professional Social Network Partner.

Once you become a Professional Social Network Partner, you'll gain access to a subset of the following APIs:

1. Profile API: Allows access to a user's Professional Social Network profile information. You can access basic profile details, pictures, and headlines.
2. Connections API: Allows access to a user's Professional Social Network network. You can retrieve the list of a user's connections.
3. Share API: Allows you to post shares for authenticated members. You can share text, URLs, and media.
4. Invitation API: Allows you to invite others to connect on Professional Social Network.
5. Organization API: Allows you to retrieve organization and brand data.
6. UGC (User Generated Content) API: Allows you to retrieve, create, and manage rich, multi-faceted content.
7. Compliance API: Allows you to report content that violates Professional Social Network's Professional Community Policies.

Getting Approved as a Professional Social Network Partner

The Professional Social Network Partner Program is open to four types of businesses:

1. Talent Solutions, for HR tech companies.
2. Marketing Solutions, for marketing automation companies.
3. Sales Navigator Application Development, for startups looking to enhance Professional Social Network Sales Navigator.
4. Professional Social Network Learning Integration, for content companies.

From what I understand, it's a long and arduous process to get a company approved as a Professional Social Network Partner. Your best bet is to select the category that best fits your company's offerings and apply to become a Professional Social Network Partner.

Most of the impressive Professional Social Network API features also require a paid subscription to Professional Social Network Developer Enterprise Products.

Profile Enrichment with the Official Professional Social Network API

Most companies will want to start with Professional Social Network's Consumer Solutions Platform (CSP). When you think of Professional Social Network, you likely think of the rich and bountiful profiles, and CSP is your access point to these alluring profiles.

There are only two features of the CSP that allow you to extract profile data from Professional Social Network:

1. Sign In with Professional Social Network provides the authentication layer to your product by allowing users to sign in with their professional Professional Social Network profiles.
2. Profile API returns structured data of a profile programmatically.

"Sign In with Professional Social Network" OAuth

Sign In with Professional Social Network is an OAuth provider for your application. Most people assume that if you use Sign In with Professional Social Network, Professional Social Network will provide every user's Professional Social Network profile. However, this is not the case. What can be returned are:

1. First/Last name
2. Email address
3. Profile picture

Also, there is a rate limit of 500 requests per day.

In my opinion, Sign In with Professional Social Network offers very little utility for most applications because the key data you want to extract is the user's Professional Social Network profile, not general information about the user devoid of any data from their Professional Social Network profile.

Fetch Person Profile Data via the Official Professional Social Network Profile API

There are two ways to fetch the data of a profile via the official Professional Social Network API:

1. The first "Sign In With Professional Social Network" method is free and available to most developers. However, you must obtain permission from each profile you wish to extract into your application.
2. The second "Profile API" method is only available to approved developers with a paid subscription to Professional Social Network's Consumer Solution Platform. This allows you to fetch profile data from any profile ID.

Using the "Sign In With Professional Social Network" Method

The first method requires you, the developer, to seek permission from the user who owns the profile. To do that, Professional Social Network requires you to fetch an access_token via 3-legged OAuth, a fancy term describing a two-step process to obtain an access token.

Step 0: Obtain a CLIENT_ID and CLIENT_SECRET by creating an app on the Professional Social Network Developers page. (You can find this page through a Google search)

Step 1: To get permission from a user, you will generate an authorization URL to send your user to Professional Social Network, where they can permit your application to download their profile.

In this case, you must provide a REDIRECT_URI, the webpage to which Professional Social Network will send the user back after they have finished granting permission.

def generate_authorization_url():
  """
  Generate an authorization URL for a user to give permission to extract their Professional Social Network Profile.

  The generated URL will take the user to a Professional Social Network page where they will be asked to give explicit
  permission to share their profile with you (the application creator).

  Should the user agree, they will be redirected to `Professional Social Network_REDIRECT_URI`.
  In the redirect, two fields will appear in the URL parameter, namely `code` and `state`.

  * `state` is generated below using `secrets.token_hex(8).upper()`. This serves as a form of identifier for this user.
  * `code` is the authorization_code, and can be used in `get_access_token()` to exchange for an `access_token`.

  """
  LI_AUTH_URL = 'https://www.professionalsocialnetwork.com/oauth/v2/authorization'
  url = requests.Request('GET', LI_AUTH_URL,
              params={
                'response_type': 'code',
                'client_id': Professional Social Network_CLIENT_ID,
                'redirect_uri': Professional Social Network_REDIRECT_URI,
                'state': secrets.token_hex(8).upper(),
                'scope': '%20'.join(['r_liteprofile', 'r_emailaddress', 'w_member_social']),
              }).prepare().url
  return url

Step 2: After a user permits you to access their profile, you'll receive an authorization code. With this code, you will exchange it for an access_token to access the user's profile.

def get_access_token(authorization_code):
  """
  Given an authorization `code`, this function will return an `access_token` which can then be used to access a user's Professional Social Network profile.
  """
  LI_ACCESS_TOKEN_EXCHANGE_URL = 'https://www.professionalsocialnetwork.com/oauth/v2/accessToken'
  access_token = requests.post(LI_ACCESS_TOKEN_EXCHANGE_URL, params={
    'grant_type': 'authorization_code',
    'code': authorization_code,
    'redirect_uri': Professional Social Network_REDIRECT_URI,
    'client_id': Professional Social Network_CLIENT_ID,
    'client_secret': Professional Social Network_CLIENT_SECRET,
  }).json()['access_token']
  return access_token

Step 3: Fetch the user's profile.

def get_profile(access_token):
  """
  Fetches the profile of a Professional Social Network user who has given you their permission to view their profile.
  """
  LI_PROFILE_API_ENDPOINT = 'https://api.professionalsocialnetwork.com/v2/me'
  r = requests.get(LI_PROFILE_API_ENDPOINT, headers={
           'Authorization': 'Bearer ' + access_token})
  return r.json()

The working Python code for this method can be found [in our Professional Social Network-api-python3-examples GitHub repository](https://github.com/nubelaco/Professional Social Network-api-python3-examples/blob/master/Professional Social Network_api_method_1.py).

Using the "Profile API" Method

The second method does not require you to seek permission from the user. However, your application must be approved to use the People's Profile API endpoint with a 2-legged OAuth.

Step 0: In your pre-approved Professional Social Network App, obtain the CLIENT_ID and CLIENT_SECRET fields.

Step 1: Using your application's CLIENT_ID and CLIENT_SECRET, exchange for an access_token.

def get_access_token():
  """
  If you are:

  1. An approved Professional Social Network developer
  2. On a paid subscription to their Consumer Product

  You can use this function to fetch an `access_token` to access the API.
  """
  LI_ACCESS_TOKEN_EXCHANGE_URL = 'https://www.professionalsocialnetwork.com/oauth/v2/accessToken'
  access_token =requests.post(LI_ACCESS_TOKEN_EXCHANGE_URL, params={
    'grant_type': 'client_credentials',
    'client_id': Professional Social Network_CLIENT_ID,
    'client_secret': Professional Social Network_CLIENT_SECRET,
  }).json()['access_token']
  return access_token

Step 2: Fetch any profile with profile_id.

def get_profile(access_token, profile_id):
  """
  Given an `access_token`, fetch the structured data of any profile.
  """
  LI_PROFILE_API_ENDPOINT = f'https://api.professionalsocialnetwork.com/v2/people/{profile_id}'
  r = requests.get(LI_PROFILE_API_ENDPOINT, headers={
           'Authorization': 'Bearer ' + access_token,
           'X-RestLi-Protocol-Version': '2.0.0'})
  return r.json()

The working Python code for this method can be found [in our Professional Social Network-api-python3-examples GitHub repository](https://github.com/nubelaco/Professional Social Network-api-python3-examples/blob/master/Professional Social Network_api_method_2.py).

Proxycurl API

The Proxycurl API offers B2B enrichment services quite like the official Professional Social Network API. In some respects, it even surpasses the capabilities of the official Professional Social Network API, though it does have its restrictions. It's worth noting that Proxycurl works exclusively with [public Professional Social Network profiles](https://nubela.co/blog/what-is-the-difference-between-Professional Social Network-public-profiles-vs-Professional Social Network-private-profiles-with-python-code-samples/).

The Proxycurl API provides the following functions:

1. People API: This feature enriches people's profiles, identifies people from emails or names, searches for prospects, and retrieves profile pictures.
2. Company API: Enrich Professional Social Network company profiles, fetch funding data, list and search employees, identify companies, and obtain the employee count.
3. Contact API: Use this to fetch personal phone numbers, personal and work email addresses, and social media profiles of anyone with a Professional Social Network profile via Proxycurl's Contact API.
4. Jobs API: This function fetches up-to-date job posting data.
5. School API: List students and enrich school profiles.
6. Search API: Perform advanced searches for people and companies.

Enrich Person Profile Data via Proxycurl's Person Profile Endpoint

Negotiating the challenges of Professional Social Network's API can be daunting. Thankfully, there's Proxycurl, which provides its [Professional Social Network API](https://nubela.co/proxycurl/Professional Social Network) so you can get everything that Professional Social Network's official Profile API offers, and a whole lot more. To see what data fields are supported, check out Proxycurl's Person Profile API documentation.

To get profile data from any profile ID, you just need to follow one method.

Step 0: Get a Proxycurl API key by signing into Proxycurl with your work email address.

Step 1: Query the Person Profile Endpoint with a Professional Social Network Profile URL.

import requests

PROXYCURL_API_KEY = '' # todo - fill this field up


def get_profile(profile_id):
  api_endpoint = 'https://nubela.co/proxycurl/api/v2/Professional Social Network'
  header_dic = {'Authorization': 'Bearer ' + PROXYCURL_API_KEY}
  params = {
    'url': f'https://www.professionalsocialnetwork.com/in/{profile_id}',
  }
  response = requests.get(api_endpoint,
              params=params,
              headers=header_dic)
  return response.json()

You can find the working Python code for this method [in our Professional Social Network-api-python3-examples Github repository](https://github.com/nubelaco/Professional Social Network-api-python3-examples/blob/master/proxycurl_people_profile_api_endpoint.py).

What if you don't have the user's Professional Social Network profile URL?

For some industries, like recruitment tech, identifying profiles of interest is a necessary step before profile enrichment. The current solution for the non-tech native involves purchasing Professional Social Network Sales Navigator and performing a Boolean search. However, Proxycurl offers a "headless" equivalent known as the Search API.

To perform a Boolean search on the Person Search Endpoint and identify people living in the US who have previously worked at Google as Software Engineers, use the following code:

import requests

YOUR_API_KEY = 'your-api-key-here'  # Replace with your API key

headers = {
    'Authorization': f'Bearer {YOUR_API_KEY}',
}

params = {
    'country': 'US',
    'past_company_name': 'Google', 
    'past_role_title': '(?i)software engineer',
}

response = requests.get('https://nubela.co/proxycurl/api/search/person/', headers=headers, params=params)

if response.status_code == 200:
    data = response.json()
    print(data)
else:
    print(f"Request failed with status {response.status_code}")

The response will include a Professional Social Network_profile_url that you can use within the Person Profile Endpoint for enrichment.

Advanced Proxycurl Features

Proxycurl supports some advanced features that the Professional Social Network API does not natively support.

Fetching Contact Information

For many use-cases, the natural next step after enriching a profile is to reach out to the person. Proxycurl's Contact API allows you to fetch three different types of contact information.

1. Work emails via the Work Email Lookup Endpoint.
2. Personal (free) emails via the Personal Email Lookup Endpoint.
3. Personal phone numbers via the Personal Contact Number Lookup Endpoint.

This contact information is not sourced from Professional Social Network, but from a myriad of other external sources.

Listing Employees or Students

You can also [fetch (or search for) a list of employees](https://nubela.co/blog/how-can-i-retrieve-a-list-of-all-employees-within-a-company-through-the-Professional Social Network-api/) from any target company or school. To get a list of past or present employees, you can use Proxycurl's Employee Listing Endpoint. The Student Listing Endpoint is available for listing graduates of any school organization.

Identifying Key People in a Company

With Proxycurl's Role Lookup Endpoint, you can easily identify the key people you need to reach out to within any company.

Profile Pictures and Company Logos

This is a freebie from Proxycurl. You can get business logos of any company with Proxycurl's Company Profile Picture Endpoint. Similarly, you can get profile pictures of any Professional Social Network Profile with the Person Profile Picture Endpoint. Both of these API endpoints are free :)

There's a whole lot more you can do with Proxycurl API, including other free API endpoints. Check out the full list of Proxycurl powers here!

Summarizing the State of Professional Social Network Profile APIs

Professional Social Network has made it extremely difficult for developers to work with their API, creating many hoops to jump through. "Sign in with Professional Social Network", while free, is throttled with rate limits and requires cumbersome per-user permission granting. Even then, you won't be able to obtain rich Professional Social Network profile data about the user signing into your service. The Profile API, with its 2-legged OAuth that lets you query any profile ID, requires you to be a Professional Social Network Partner and necessitates a hefty payment via a Professional Social Network subscription.

Proxycurl offers an [alternative equivalent to Professional Social Network's Profile API](https://nubela.co/blog/ultimate-guide-to-Professional Social Network-api_people-profile-api_with-python-examples/). The key difference lies in latency and data completeness. Proxycurl's Person Profile Endpoint performs a live scrape of a profile on each API call, so each call might take a few seconds to complete. To overcome throughput, a developer can launch requests to Proxycurl's API in parallel.

Proxycurl is cost-effective and eliminates most of the headaches involved with pulling data from Professional Social Network—even when compared to the official paid tools available from Professional Social Network, like their own limited API or Professional Social Network Sales Navigator.

Give Proxycurl a try today.

P.S. Do you have any questions about Proxycurl or how we scrape data from Professional Social Network and beyond? Reach out to us at “hello@nubela.co”, and we would be happy to help.

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!

TL;DR

If you're asking is scraping LinkedIn legal in 2026, the narrow answer is: scraping public LinkedIn data is not automatically criminal under the CFAA after hiQ. The useful answer, the one that matters if you run a company, buy data, or build product on top of it, is harsher: legal does not mean safe. LinkedIn can still drag you into a civil lawsuit, use its User Agreement against you, demand your code, your downstream data, your customer list, and a couple years of your life. I know because I was sued by LinkedIn, and Proxycurl and I have since settled.

“Just because it is legal doesn't mean that LinkedIn won't have any recourse. The TOS are a contract and if they can prove damages because Apollo and Seamless violated that contract they may have a claim against them.”

Apollo and Seamless booted from LinkedIn?
by u/Far_Tomorrow7860 in r/sales

Why I'm writing this

The day we signed the settlement, I understood something I had spent ~6 years arguing against: there is no version of building on LinkedIn data that is safe. Not scraping, not buying from a broker, not “just enriching.” Not any of it.

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 the case with LinkedIn. I am not going to relitigate it here, and I'm not going to disclose settlement terms beyond that line.

What I am going to do is tell you what I wish someone had told me in 2019, when I wrote a post titled Is LinkedIn Scraping Legal? on Nubela's blog. That post is still up. I still stand by the narrow CFAA analysis in it. What I no longer stand by is the comforting inference people took from it, namely: “therefore LinkedIn data is safe to build on.” That part was wrong.

And yes, that is a painful sentence to write.

Most founders, RevOps teams, and buyers of B2B data operate on a cartoon version of legal risk. They think the question is binary. Legal or illegal. Fine or not fine. That's not how this works once a real plaintiff with real lawyers shows up.

Legal ≠ Safe

If you only remember one line from this article, make it this one: legal is not the same thing as safe.

When people ask, “is scraping LinkedIn legal,” they usually mean one of four different things and mash them together:

1. Criminal law: can the state prosecute me?
2. Civil statutory liability: can a private plaintiff sue me under a statute, like the CFAA under 18 U.S.C. § 1030(g)?
3. Contract liability: did I breach the User Agreement?
4. Everything else: unfair competition, misappropriation, trademark, unjust enrichment, the usual kitchen-sink stuff.

The case everyone cites is hiQ Labs v. LinkedIn, 31 F.4th 1180 (9th Cir. 2022). What that case actually gave people was a narrow win on a narrow question: scraping public LinkedIn pages did not cleanly fit the CFAA's “without authorization” theory in that posture.

What it did not hold:

• that LinkedIn scraping is generally safe
• that contract claims disappear
• that California state-law claims disappear
• that buying LinkedIn-derived data from someone else saves you
• that a cease-and-desist is a joke

This is where I need to eat my own cooking a bit.

My 2019 post literally said: “You'd still have to be compliant with websites' ToS.” It also said: “Deal with public [LinkedIn] profiles only? Ok. Scrape [LinkedIn] profiles with fake logged-in accounts? Not ok.” People remembered the headline. They forgot the caveat. Frankly, I probably underestimated how badly that caveat would matter in the real world.

So if you want the operator answer to is scraping LinkedIn legal in 2026, here it is: public scraping may be outside one narrow CFAA theory, but that does not make your business safe from LinkedIn. Those are different questions, and confusing them is how people end up burning years of their life.

The User Agreement catches everyone

This is the part most people in B2B data have not actually read. They talk about “public data” as if that ends the discussion. It doesn't. The contract is the tripwire.

Almost everyone reading this is bound by it

LinkedIn's complaint says the platform had over one billion members at the time. If you have a LinkedIn account, had one, or your company has a LinkedIn Page, you almost certainly clicked into a contract.

LinkedIn's current User Agreement says, in plain English, that by creating an account or accessing or using the services, you're entering a legally binding contract. This is not subtle. This is not buried in a weird annex. It's up front.

That matters because breach of contract is the cleanest, least romantic claim in the world. No hacking movie soundtrack. No hand-wringing about whether scraping is “theft.” Just: you agreed to this, then you did the thing you said you would not do.

The Agreement does not stop at scraping

Most people know there is a scraping clause. Fewer people know there is a buyer clause.

From LinkedIn's User Agreement, § 8.2(2):

“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. That's the obvious one.

Now read § 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 phrase, “whether directly or through third parties ... data aggregators or brokers,” is the line most buyers have never internalized.

If you're a LinkedIn member and you bought a CSV, enrichment feed, or “professional contacts” dataset from a broker, and any of that came from LinkedIn, LinkedIn has a very obvious place to point in its contract. Public or not public does not save you there. “We bought it from a vendor” does not save you there. “The vendor is outside the US” does not save you there.

Then there is § 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.”

And § 8.2(13):

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

This is not a narrow anti-scraping rule. It's a whole perimeter.

Pages pull companies in too

If your company has a LinkedIn Page, congratulations, the company clicked into this too.

The complaint against us walked through Nubela's and Proxycurl's Pages and pointed out that creating a Page required affirmative agreement to LinkedIn's Pages terms, which incorporate the User Agreement. It also used that contract theory, together with forum-selection language, to pull a Singaporean company and a Wyoming LLC into the Northern District of California.

This is the part people skip because it feels administrative. It isn't. Your company page is not just a marketing asset. It's also a signed piece of paper, functionally speaking.

Deleting your account does not save you

This one tends to stop people cold.

Section 5 of LinkedIn's User Agreement contains a survival clause. It says the following survive termination: Sections 4, 6, 7, and 8.2.

Section 8.2 is the whole “Dos and Don'ts” machinery. Scraping, copying, third-party broker use, resale, bots. All of it.

And Section 6, the governing law and dispute machinery, survives too.

Translation: you do not get to click “close account” and magically un-sign the contract you already signed. If you were bound, the restrictions that matter here can keep traveling with you.

The practical consequence

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

Notice I said plausible. I'm being precise here.

Whether they sue is their business decision. Whether they can build a complaint around it is a different question. And after being the person on the receiving end, I no longer think founders should comfort themselves with the second question.

“I got logged out of my account and LinkedIn gave me a warning that they detected automation software and I could get banned if it continues. It’s annoying because I wasn’t automating anything but I did delete the Apollo extension asap.”

With the Linkedin crackdown on Apollo, Seamless etc.,what tools do ...
by u/FreshPrince2308 in r/sales

What the complaint actually said

Abstract legal debates are cute right up until you read a real complaint with your own name in it.

Six claims, stacked

LinkedIn's complaint against us 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 because even if you think half of that is bullshit, you still have the other half. Federal litigation does not need every claim to be a winner in order to wreck your year.

They used my own blog post against me

This was the most humbling part for me personally.

LinkedIn quoted my own 2019 blog post as an admission against interest. Not a competitor's rant. Not some internal Slack leak. My own published writing.

From Complaint ¶60:

“Defendants caution that 'lines are blurred should you choose to scrape another's website, without their explicit permission or in disregard of their Terms of Service (ToS). This is where things become a little tricky. Freely extracting data from another site could be argued as trespassing or theft.'”

From ¶61:

“Defendants are aware that 'very clear evidence' that scraping is unlawful is 'creation of fake accounts to access otherwise-inaccessible users' data.'”

And again from ¶61:

“Defendants aptly summed it up: 'Clearly fraudulent activities are a big no-no in web scraping.'”

I wrote those lines to be responsible and nuanced. LinkedIn used them to show that I knew the terrain was dangerous.

That's not LinkedIn being sneaky. That's just litigation.

If you run a data company and publicly write about the legal edges of your business, assume every sentence might one day get printed, highlighted, and handed to a judge. Because it might.

The prayer for relief is the scary part

The complaint's prayer for relief is the part founders should read twice.

Complaint ¶121 asked for:

“An order requiring Defendants to destroy all documents, data, and other items, electronic or otherwise, in their possession, custody, or control, that were wrongfully extracted and copied from LinkedIn's website, along with any data that Defendants have inferred, aggregated, or synthesized as a result of data wrongfully extracted and copied from LinkedIn's website...”

Then ¶122:

“An order requiring Defendants to destroy all software code and other instrumentalities for scraping LinkedIn's platform...”

Then ¶123:

“An order requiring Defendants to notify all customers that purchased or otherwise acquired access to scraped data from LinkedIn of any decision or award against Defendants..."

Read ¶121 again. “Inferred, aggregated, or synthesized.”

That is not just “delete the raw rows.” That reaches downstream derivatives. If your model weights were trained on LinkedIn-derived features, good luck explaining why those weights are spiritually different. If your product dashboards, scores, or enrichment layers were built on top of disputed data, they're in the blast radius too.

This is where people who say “we don't scrape, we just enrich” are kidding themselves.

Discovery is the punishment

The complaint is the visible part. Discovery is where your life gets expensive.

Six claims means six fishing lines

Every claim opens a different line of attack.

Breach of contract? They want evidence you agreed, knew, and breached.

CFAA? They want to talk about authorization, account use, access patterns, infrastructure, proxies, browser flows.

Trademark? They want marketing materials, website copy, extension screenshots, sales collateral.

UCL and misappropriation? Enjoy the broad sweep.

One lawsuit can become six parallel excavations into how your company actually works.

Everything gets opened up

If you have never been close to discovery, here's the operator version.

It means, potentially:

• every email matching terms like linkedin, scrape, extension, proxy, captcha, sales nav
• every Slack thread where someone made a cute joke about “borrowing” data
• every Git commit touching scrapers, browser automation, parsers, login flows, anti-detection workarounds
• every Jira ticket and CI log
• every database schema that ever stored a LinkedIn URL, member ID, or copied profile field
• every vendor deal with proxy providers, browser farms, CAPTCHA solvers, data brokers
• every customer contract tied to those outputs
• every old bucket or backup you forgot existed

This is why I say legal is not the same as safe. You can have a debate-worthy legal theory and still be completely, utterly unsafe as a business.

The asymmetry is the point

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

That matters.

There is an economic asymmetry baked into this system. A company like LinkedIn can spend millions on litigation and keep functioning. A bootstrapped or venture-backed data company can be legally interesting and economically dead at the same time.

Settlement is often not some moral confession. Sometimes it is just arithmetic.

That was true in my world too. I am not going to pretend otherwise.

Why buyers should care too

If you buy LinkedIn-derived data from a vendor and LinkedIn sues the vendor, you do not get to stay magically offstage.

You can get subpoenaed.

Your procurement emails get read. Your Slack messages get read. Your “do we know where this really comes from?” messages get read. Your diligence process, or lack of one, gets exposed.

The buyer fantasy is that the vendor is the shield. In reality, the vendor is often just the first domino.

“You will get banned, all your accounts, if you continue to bypass, there will be threat of legal action. it’s not sustainable buisness model.”

Linked In Scraping legal Situation?
by u/Jaded_Marionberry771 in r/n8n

Apollo and Seamless were the warning shot

My case was not the beginning of enforcement. It was one rung on a ladder.

Public reporting from MarTech said that sometime around March 6, 2025, Apollo.io and Seamless.ai disappeared from LinkedIn. LeadGenius and LiGo both wrote about the removals as part of a broader crackdown on scraping and extension-based data extraction.

The important part is not whether every outsider interpretation of motive is perfect. The important part is that LinkedIn removed official Company Pages without filing a public lawsuit first.

That tells you a lot.

There is a graduated enforcement ladder here:

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

The ladder is real because we have seen multiple rungs in the wild.

And once you understand that ladder, the question is scraping LinkedIn legal in 2026 starts sounding childish. Sorry, but it does. The adult question is: what can LinkedIn do to me, contractually and operationally, before I ever get a chance to win an argument on the merits?

That answer is: quite a lot.

“Apollo & Seamless had their entire company pages deleted from Linkedin yesterday for violating their terms of service by scraping data”

With the Linkedin crackdown on Apollo, Seamless etc.,what tools do ...
by u/FreshPrince2308 in r/sales

And if you want the market's blunt version, here's one from X:

LinkedIn has no official MCP server. While clever, this is a browser scraper using your credentials, one LinkedIn policy change from breaking, and one ToS violation from getting your account banned. Cool hack. Risky business tool.

— Mister Lee (@MisterLeeHODL) Sun Apr 12 23:12:03 +0000 2026

I think that post is basically right.

Cool hack. Risky business tool.

The only safe path is data without LinkedIn

This is the point where I stopped arguing the other side.

If you are building, using, or scaling with B2B data, the only durable path I trust now is: use data that does not have LinkedIn as a source.

Not “mostly not.” Not “not directly.” Not “we only use it for enrichment.”

Not at all.

What no LinkedIn data actually means

This standard is stricter than most founders want to hear.

It means:

• no LinkedIn-sourced rows in production, staging, dev, or notebooks
• no LinkedIn URLs, member IDs, or copied profile fields in code paths
• no LinkedIn content in training data, prompt corpora, eval sets, or fine-tuning runs
• no browser extensions touching linkedin.com
• no vendor whose vendor touched LinkedIn
• no old Git blobs with scraper code “but we deleted that months ago”
• no archived backups you are hoping nobody asks about

Because here's the problem: once the bell has been rung, you do not get to unring it.

If your model has seen the data, the provenance problem is now inside the model. If your customer-facing product is downstream of it, the problem moved downstream with it.

This is exactly why a clean-room posture is so much cheaper than a litigated cleanup.

Why I'm building NinjaPear this way

I am building NinjaPear with a zero-LinkedIn-data posture. Not as a marketing gimmick. As a survival rule.

NinjaPear is a B2B company intelligence platform, and the whole point is that it is built on other lawful, durable, public-web and first-party style signals, not on LinkedIn. If I mention products here, it is only because they reflect that posture: the Customer Listing API maps customer and partner relationships from the public web, and the NinjaPear docs are explicit about data ownership and ethical sourcing.

I'm not interested in clever workarounds anymore.

I did the clever phase already.

Now I care about whether a company can still exist in 10 years.

And for me, after being sued, the answer is straightforward: if LinkedIn data touched the building, the company has a timer on it.

One more thing, because people always ask this after I explain the posture.

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

The reason is not that we want to scrape LinkedIn. We do not. The reason is simpler: the User Agreement is broad enough, and survives long enough, that the only exposure level I trust is zero.

Some people will call that excessive. Fine.

After living through a real complaint, “excessive” is the first level of caution I actually believe.

My actual answer

So, is scraping LinkedIn legal in 2026?

My answer is this:

• Narrow legal answer: scraping public LinkedIn pages is not automatically criminal under the CFAA after hiQ.
• Real founder answer: no version of building on LinkedIn data is safe.
• Buyer answer: buying it from a broker does not magically clean the provenance.
• Operator answer: the User Agreement is the trap, discovery is the punishment, and the business risk is bigger than the headline legal question.

If you are already using LinkedIn-derived data, assume LinkedIn's lawyers walk into your office tomorrow and subpoena everything.

Ask yourself four ugly questions:

1. Can you prove where every row came from?
2. Can you state under oath whether your models saw LinkedIn-derived data?
3. Can you notify every affected customer if forced to?
4. Can your runway survive discovery?

If those questions make your stomach tighten, that is your answer.

This article is not legal advice. Talk to your own counsel for your own situation. But from one operator to another, I can tell you this much with more conviction than I had in 2019: do not build your company on LinkedIn data.

If you need a practical next step, audit your stack this week. Vendors, extensions, CRM fields, model inputs, old buckets, Git history, all of it. Start with the checklist below.

If you're building a data product from scratch, start with sources that do not route through LinkedIn at all. That is the only posture I trust now. It is the posture I'm building with NinjaPear, and it is the one I would recommend to any founder I actually like.

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://ligosocial.com/blog/linkedins-major-crackdown-on-data-scraping-apollo-and-seamless-company-pages-gone
7. 18 U.S.C. § 1030. 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.

“still shows people at companies they left months ago, titles are outdated, emails bouncing even after running verification. spending more time cleaning lists than actually doing outreach.”

Can't use Apollo anymore, whats a better alternative for prospecting?
by u/executivegtm-47 in Sales_Professionals

What this guide does

This is a developer guide for building lookalike prospecting into 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’s what I’m going to walk through, code first, with sample responses, normalization logic, and the operating rules that keep the whole thing from turning into expensive bullshit.

Lookalike prospecting, without the bullshit

Lookalike prospecting is just generating new accounts or people that resemble proven wins across fit, context, and timing. Not “same employee count” and not “same tech stack, probably.” Most so-called lookalike systems are just firmographic cloning with an AI sticker slapped on top.

They fail for boring reasons. Dirty seeds. Weak signals. No suppression layer. Opaque scoring nobody can defend when a rep asks why some random account got pushed to the top. When I was running FluxoMetric, I burned ~4K/mo on tools that gave me worse targeting logic than a spreadsheet with three weighted columns.

Clean input looks like this: start with closed-won first, split by use case, then exclude customers, churn, open opps, partners, agencies, and test junk before you enrich anything. A 20-account clean seed beats a 2,000-account dirty seed. Every time.

And the signal hierarchy is not equal. Firmographics are table stakes. Technographics add context. Relationship data is stronger. Trigger data handles timing. In practice, relationship data beats generic similarity most of the time, and trigger data should rank prospects, not create them from thin air.

“It still shows people listed at companies they left months ago, titles that are outdated and emails bouncing even after running verification”

Best Apollo alternative for prospecting in 2026?
by u/BessieFlamboyant in coldemail

The 4 agent loops

My preferred lookalike prospecting system has 4 loops, because each one solves a different problem.

1. Competitor to customers gives you fast account expansion.
2. CRM accounts to competitors gives you the cleanest 0→1 market widening.
3. CRM contacts to similar people gives you the real 1→N motion.
4. Triggers to outreach gives you timing.

Do not jam all four into one giant workflow on day one. That’s how you end up with a fragile automation blob nobody trusts.

Loop 1: Competitor to customers

Problem: You know a competitor or adjacent company and want a prospect list fast.

Solution: Use the Customer Listing API to find companies already buying from that vendor or sitting in its ecosystem. This is the fastest path from one website to a prospect universe that doesn’t feel made up.

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",
      "website": "https://www.sequoiacap.com",
      "id": "def456",
      "industry": 40203010
    }
  ],
  "partner_platforms": [
    {
      "name": "Amazon Web Services",
      "website": "https://aws.amazon.com",
      "id": "ghi789",
      "industry": 45101010
    }
  ],
  "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 into ProspectAccount
• 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,
  "total_score": 0.6225
}

Outreach angle: You already sell in the same ecosystem as Stripe. We’re not guessing fit from generic firmographic filters.

A few doc details matter here. The endpoint costs 1 credit per request + 2 credits per company returned. quality_filter=true is on by default, which filters out junk TLDs and unreachable websites. That one flag alone saves a stupid amount of cleanup.

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. Why? Because it starts from accounts you already know you can win.

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:

That split matters. Product category overlap usually beats organic SEO overlap because it points to actual budget competition, not just shared keywords.

“The stale data problem you're describing isn't really an Apollo problem, it's a database problem... by the time you're reaching out the information is already months old.”

Can't use Apollo anymore, whats a better alternative for prospecting?
by u/executivegtm-47 in Sales_Professionals

That comment is exactly why this loop works. It does not pretend an old giant contact database is strategy. It starts from companies you’ve already proven are close to your real market.

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 strongest loop in the whole stack if your CRM has good work emails. Similar People is the real 1→N motion.

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
}

And yes, here’s the context-specific outreach example 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?”

I would never ship that as default copy. I’d use it only when the account is already strong and the underlying evidence is real. If the agent cannot show evidence, the rep should not send the email.

NinjaPear’s published Similar People benchmarks are actually useful here. The launch post showed:

• 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 drop lower in the org chart is normal. Public executives are easier. Mid-level humans are messier.

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 should rank prospects, not create them.

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
}

This is the prioritization layer. Not the discovery layer.

The pricing examples in the Company Monitor launch post are refreshingly concrete:

• 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’s enough to actually budget the loop, which is more than I can say for most “intent” products.

Repo structure

If you’re publishing a code tutorial, the repo packaging matters more than people think.

Push from the real project root, not from a parent wrapper folder. This sounds stupidly obvious, but people screw it up constantly.

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

I created the public repo for this article here:

“At your volume with stable workflows you're just paying a premium for a pretty UI at this point... we started moving orchestration to n8n two months ago and haven't looked back.”

Is Clay still worth it after the new pricing changes?
by u/noobCoder00101 in gtmengineering

That’s the workflow overhead problem in one sentence. Clay can be useful. But once your logic stabilizes, paying orchestration tax forever gets old fast.

Core Pydantic models

This should stay practical. Pydantic is useful here because it forces your system to carry evidence, not just vibes.

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

The schema is not the interesting part. The important part is that every prospect drags its evidence trail with it all the way to the rep-facing output.

NinjaPear client wrapper

Use a thin wrapper. Don’t build a fake framework when a small client class will do.

Also, if you’re using an AI coding agent, point it to https://nubela.co/llms-full.txt. It already contains the endpoint references, rate limits, errors, examples, and enough procedural detail to stop your agent from doing dumb things.

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-ups for competitor listing, similar people, and company updates. Keep it boring.

A few implementation details from the docs are non-negotiable:

• normal rate limit is 300 requests/minute
• the rate-limit window is 5 minutes, so burst is 1,500 requests per 5 minutes
• long-running endpoints can take 30 to 60 seconds
• recommended timeout is 100 seconds
• handle 429 with exponential backoff

That’s real API behavior, not theory.

Scoring and suppressions

This section is where teams overcomplicate things and disappear up their own asses.

Keep the score simple enough that a rep 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,
    )

And keep suppressions brutally simple too.

def is_suppressed_account(account, suppression_websites: set[str]) -> bool:
    return str(account.website) in suppression_websites

Suppress these before enrichment:

• existing customers
• churned accounts
• open opps
• partners
• agencies
• internal test domains
• bad domains

If you enrich first and suppress later, you just paid to polish garbage.

I also do not trust black-box intent. Most intent products cannot explain why an account is “hot” in a way a rep can actually use. That’s not intelligence. That’s horoscope software for RevOps.

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 rule sounds strict because it should be. I’ve seen too many teams let a model freestyle outreach from thin air, then wonder why reps stop trusting the system.

How to run the project

Here’s the 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. A blog post should teach you the architecture. It should not pretend to replace the whole API reference.

What to measure

Track performance by loop, not just in aggregate.

• loop source
• suppression rate
• enrichment rate
• reply rate
• meeting rate
• opportunity rate

If your Similar People loop produces fewer rows but 2x the meeting rate of your competitor loop, then congratulations, you found your real motion. Stop worshipping list size.

Mistakes to avoid

Keep this section punchy because the mistakes are obvious.

• 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

A lot of lookalike prospecting systems fail because the operator wants automation before clarity. That order is backwards.

If you want the right next step, it’s not “go buy more data.” Clone the repo, run the four loops against your own closed-won seeds, and inspect the evidence trail for every prospect the system produces. That’s how you build lookalike prospecting that a real sales team will actually trust.

Most lead generation content is useless if you actually have to build the damn system yourself. 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.

AI SDRs are the most overhyped thing in SaaS right now.

Not because AI is bad.
Because the input is bad.

An AI writing personalized emails to 10,000 random contacts is still spray and pray.

You just automated the waste.

— Junaid Choudhary (@JustJunaidHere) Tue Apr 14 13:00:01 +0000 2026

Build the system first

When I was running FluxoMetric, this is the mistake I made for way too long: I thought better modeling would fix bad market inputs. It does not. It just gives you prettier wrong answers.

If I were building lead generation for a startup today, and my two obvious competitors were Stripe and Shopify, I would start with this system shape:

• 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 is how you build a faster bullshit cannon
• 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 is going to do: take those four loops, wire them into one practical workflow, and show you the exact code and response shapes I would use if I were a founder trying to steal market share from better-funded competitors.

This is the whole workflow in one glance:

seed domains -> customer loop -> competitor loop -> people loop -> timing loop -> queue

And here is the boring main() that matters more than 90% of AI SDR demos on X:

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

Short. Good. Most systems should be this obvious.

The stack

Keep the stack brutally practical:

• 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, because those are not the point of this guide

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"],
)

And yes, you can run PydanticAI through OpenRouter cleanly:

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 is simple: the model matters less than the data and the wiring. Most agentic lead generation demos fail because they are dressed-up toys sitting on bad data.

NinjaPear’s docs make the operational constraints pretty clear too:

• 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 real infrastructure guidance. Not marketing garnish.

Loop 1: Pull competitor customers

If I were a founder selling into companies that already buy from 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 would already compare you against.

For this guide, I am using:

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.

Doc-backed details that 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 enjoy 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 actually 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):
    api = ninjapear.CustomerAPIApi(api_client)
    return api.get_customer_listing(website=website)

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 care about the relationship buckets differently.

And I flatten the response like this:

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

Here is a sample response shape using documented NinjaPear fields:

{
  "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"
}

What I do not do is dump investors and partner platforms straight into the outreach queue. That is how people end up bragging about lead volume while quietly burning sender reputation.

Stop Using Apollo for Leads the Database Is Already Burned
by u/Singh_Acquisitions in coldemail

“When thousands of marketers, agencies, and freelancers are all buying from the same database, those contacts get absolutely hammered with pitches long before you ever hit send.”

Yep. That is exactly why customer-graph-first lead generation beats database-first lead generation.

Dedupe the account list

Dedupe by normalized domain.

Not company name. Not the CRM label your rep typed in a hurry. 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 find the adjacent terrain.

This is where the system stops being a list puller and starts becoming a market mapper.

Find adjacent competitors

Use the Competitor Listing endpoint to pull adjacent and overlapping companies.

The docs show this clearly enough to act on:

• Endpoint: GET /api/v1/competitor/listing
• Cost: 2 credits per competitor returned
• Minimum request cost applies even when the result is weak

A thin wrapper is enough:

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
}

That is already enough to do useful work. You do not need a giant ontology sermon here. You need plausible adjacent companies and the reasons they overlap.

Expand one layer at a time

Do not recurse like a lunatic.

One layer is usually enough to improve lead generation coverage without turning the queue into broad-market mush.

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

Track provenance

Every discovered account should carry provenance:

• which seed exposed it
• which competitor chain exposed it
• what relationship type got it into the graph

That becomes useful later for scoring and messaging. If an account appears as a Stripe customer and again through an adjacent payment competitor, that is not duplication. That is signal.

Stop the loop early

Use three brakes:

• max_depth
• domain dedupe
• account caps

If you do not cap this, you end up exploring the entire category and pretending that is pipeline generation.

A concurrency-safe version is fine later. Get the logic right first.

# pseudocode
async for website in frontier:
    if website not in visited and len(discovered) < account_cap:
        fetch competitor listing
        append new domains

I found a quote on X that says this pain more honestly than most GTM decks do:

This is why agency bros don’t impress me

Super easy to blast the TAM and get some results

Super hard to work a set of 100 qualified accounts for the year and penetrate 10-20% of them

The latter is what I’m paid to do

— Khalifa (@saleskhalifa) Fri Apr 10 16:05:09 +0000 2026

That is the whole point. Better lead generation is usually about better market mapping, not just more names.

Loop 3: Find similar people

This loop is where a lot of people get stupid.

If you run people discovery before account scoring, you just built a faster bullshit cannon.

Start with the account

Only run people discovery on accounts that already passed some fit threshold.

For example:

• competitor customer
• sensible headcount band
• recent public updates
• category relevance from the source chain

Do that first. Then go looking for humans.

Pull role-alike people

The Similar People endpoint is built for role-alike discovery.

That means you can start with a target role and pull similar profiles at relevant companies.

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 a founder building this for a payments-adjacent product, I would start with one clean role like Head of Revenue Operations or VP Sales Operations.

Not vague mush like “operations lead.”

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 to enrich from:

• work email
• name + company
• role + company

NinjaPear’s own Person Profile write-up gave useful match-rate guidance:

That is exactly what I would expect. Role + company is useful, but weaker than deterministic inputs.

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 from the documented Person Profile style:

{
  "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, not an export dump.

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

And because fake personalization is a plague now:

How do you personalize at scale without it becoming fake or too "AI"
by u/LifeSuccessful9302 in coldemail

“The secret is to stop using AI for 'openers' and start using it for 'relevance logic'...”

Exactly. Use AI for routing and relevance. Not for one more creepy sentence about a podcast appearance.

Loop 4: Enrich and monitor

If your workflow has no timing layer, it is not agentic lead generation. It is a nicer spreadsheet.

This is the part I care about most, because this is where the system stops being static.

Enrich the account

Use these NinjaPear endpoints:

• Company Details for context
• Employee Count for fit and segmentation
• Company Funding for capital signal
• Company Updates for recent public changes

Here is the endpoint map I would actually hand to an engineer:

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-style 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-style shape:

{
  "website": "https://stripe.com",
  "employee_count": 8000
}

Sample Company Funding-style 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 lead generation becomes timely instead of decorative.

NinjaPear’s Updates docs are refreshingly direct. The product tracks:

• blog posts
• X posts
• meaningful website changes

And the output can be consumed as RSS. Good. That means you can pipe it into Slack, a CRM worker, or a queue without inventing another ugly polling layer.

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 pricing examples in NinjaPear’s Company Monitor launch post are also useful sanity checks:

Those are low enough that a founder or a small GTM engineering team can test timing-based lead generation without making it a budgeting drama.

Set up monitoring

The docs describe the Monitor API as returning an RSS feed of company changes.

If the exact SDK call shape moves around later, keep the wrapper isolated so you only change one file.

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

The scoring stub from the plan is good enough to start:

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

And here is the output signal table I would use:

If you want a person score too:

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)

More outreach is not better outreach. Timed outreach is better outreach.

Most email outreach agencies are just spam factories in disguise.
by u/Difficult-Arrival665 in b2b_sales

“The real issue is agencies optimize for volume because that's what they can sell, not what's actually gonna work for your specific ICP.”

Exactly. Timing and fit beat volume theater.

Wire the PydanticAI agent

Do not turn this into a full PydanticAI tutorial. You only need enough structure for typed orchestration.

I keep orchestration in one place. Not one script for customers, another notebook for people, and a mystery automation in some no-code tool nobody wants to own.

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 function:

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.

What matters is not the agent ceremony. What matters is that your lead generation system returns typed structures, not a blob of optimistic prose.

Add NinjaPear tools

This is the practical bridge between docs and working code.

I put the wrappers in app/tools/ninjapear.py.

Required wrappers in the project:

• 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

The rule I used in the repo is simple:

• NinjaPear code is real
• non-NinjaPear helpers are mocked on purpose

Model table:

And yes, I mock these 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 honest in your build. Mock what you do not actually provide yet. Fake integration theater is how teams confuse themselves.

Build the full GitHub project

I built the starter repo for this article here:

GitHub: https://github.com/NinjaPear-Shares/agentic-lead-generation

Two implementation details the admin specifically asked for are now handled properly:

• the repo root itself has a README.md, not a nested project folder pretending to be the root
• the README.md links back to this article at https://nubela.co/blog/agentic-lead-generation

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. Not a spreadsheet. Not a PDF full of fluff. Actual code.

Run an end-to-end example

Now let’s run the whole lead generation flow from the perspective of a founder using Stripe and Shopify as the competitive 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, in order:

1. Pull customer lists for Stripe and Shopify.
2. Expand 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 the email send mocked until the queue quality is real.

Because this is also true:

Why did AI SDRs fail?

Because their data was wrong

they were optimizing for leads

not for revenue generated

...

Data Pipeline + Data Warehouse + Agent Infrastructure

— Cody Schneider (@codyschneider) Wed Apr 15 18:00:01 +0000 2026

I agree with the important part. The bottleneck is usually not the model. It is the data layer and the workflow.

Use the NinjaPear Skill

If you already use an AI coding agent, install the NinjaPear Skill first.

Seriously. It will save you dumb mistakes on auth, pagination, endpoint selection, and error handling.

NinjaPear’s docs say the Skill teaches coding agents:

• 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 belongs in this guide because the entire point is shipping agentic lead generation that actually works.

Not prompt theater. Not “look what my SDR agent wrote.” Real integration code.

If you want the blunt version, here it is.

Most lead generation content is still explaining funnels to people who need systems.

What actually matters is whether your stack can answer four things, in order:

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 system cannot answer all four, your “agentic lead generation” stack is mostly branding.

So here is the honest next step: 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 article. You will learn more from one afternoon of real implementation than from ten generic lead generation posts pretending CSVs are strategy.

And if you are building with Claude Code, Codex, or Opencode, install the NinjaPear Skill before you touch the code. It will save you a bunch of stupid mistakes.

The first time true people search helps you identify a mystery caller, it feels clever. The first time you search your own name and see your address history sitting there for strangers, it feels like a small privacy horror show.

How do you get your data off true people search?
by u/rockhardpebble0 in r/privacy

I’ve spent too many years inside ugly data products to pretend otherwise. TruePeopleSearch is useful. It is also invasive in a way that stops being abstract the second you run your own name.

My blunt take: it’s genuinely good for quick reverse phone lookups, checking an address trail, and finding a person when you only have partial info. But the privacy tradeoff is not some accidental side effect. It’s baked into the category.

TL;DR

If you want the fast answer before the long answer, here it is.

My blunt take after testing TruePeopleSearch and its alternatives

Here’s the answer without the usual content-mill throat clearing.

TruePeopleSearch is useful. If you need to do a quick reverse phone lookup, check whether a person still ties to an old address, or find someone when all you have is a partial name plus state, it often gets you useful info faster than prettier paid sites.

That’s the good half.

The bad half is what happens when you search yourself. Current and past addresses. Phone numbers. Relatives. Associates. Sometimes property-related context. Suddenly the product stops feeling clever and starts feeling invasive.

That tension is the whole story. The product is helpful precisely because it aggregates personal details many people do not expect to be this searchable in one place.

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 actually gives you for free

Most articles about true people search either moralize or hand-wave. Neither helps. So here’s the practical answer.

According to the official Google Play listing for the TruePeopleSearch app, the service offers:

• name search
• reverse phone lookup
• reverse address lookup
• current and past addresses
• phone numbers
• relatives / associates / friends
• email addresses
• possible property information
• possible business listings

The same listing says it has updated records on “nearly every single adult living in the US” and that users can get “full address histories, phone numbers, email addresses, relatives, friends, associates, property information & more.”

That’s why it gets used. It solves very specific low-friction problems:

• “Who owns this number?”
• “Is this old address still tied to them?”
• “Do I have the right John Smith in Arizona?”

For those jobs, it can work damn well.

What “100% free” really means

This is the cleanest explanation of the business model, and it comes from the app listing itself:

That matters.

Because “100% free” is technically true and strategically incomplete. You may not pay with a card, but the experience is still monetized. The friction shows up in ads, sponsored links, and partner funnels if you click the wrong thing.

That doesn’t make it fake. It does mean the product is not working purely in your interest.

Feature-by-feature scorecard: TruePeopleSearch vs FastPeopleSearch vs Whitepages vs Spokeo

I care less about whose homepage looks cleaner and more about who gets me useful information with the fewest stupid clicks.

My ratings rubric

I’m not handing out stars based on vibes.

• Freshness = how often moved addresses / changed numbers seem reflected
• Richness = how much useful info appears before a paywall
• UX clarity = how hard it is to avoid ads / sponsored junk and get to the real action
• Privacy posture = how understandable the opt-out is, whether removals appear to stick, whether re-checking is necessary
• Trustworthiness = whether the product feels like it is helping you or steering you

That last one matters more than most reviews admit.

A people-search engine is already asking for a lot of trust. If the interface feels like a carnival game, I downgrade it hard.

The privacy tradeoff is the real product

This is the emotional center of the whole true people search conversation.

The utility exists because the site aggregates personal details people do not expect to be this searchable in one place. Current and past addresses. Phone numbers. Relatives. Associates. Possible property data. That’s the value.

It’s also the reason normal people get creeped out the moment they search themselves.

Incogni’s TruePeopleSearch removal guide says removals usually work within 24-72 hours, but also notes that your information may reappear as the site refreshes public records. That caveat is not some minor footnote. It changes how you should think about removal entirely.

Removal is not a one-and-done event. It is maintenance.

What users are actually upset about

People are not mainly upset because the site looks cheap. They’re upset because their home address is online and searchable by strangers.

“they have my information with location and addresses. I have no idea how this site is even legal...”

How do you get your data off true people search?
by u/rockhardpebble0 in r/privacy

“I have tried 7 times so far with the removal request but no luck.”

How do you get your data off true people search?
by u/rockhardpebble0 in r/privacy

And this broader X post hit because the fear is obvious to anyone who has ever searched themselves on one of these sites:

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’s enough to explain the economics cleanly.

You are not paying cash for the lookup.

Instead, your attention is monetized, and the usefulness of the product is tied directly to the existence and visibility of personal data.

How the TruePeopleSearch opt-out actually works in 2026

The basic removal flow is not complicated. The friction is in the details.

Core flow:

1. Visit https://www.truepeoplesearch.com/removal
2. Enter your email, complete CAPTCHA, and start removal
3. Search by full name, city, and state
4. Open the correct listing
5. Scroll down to Remove This Record
6. Confirm via email
7. Re-check after the stated removal window

I also hit a Cloudflare block when trying to access the removal page directly during testing, which is worth calling out because it adds yet another layer of friction for people just trying to remove themselves.

Incogni’s walkthrough says the process usually takes 5-10 minutes and that removal often works within 24-72 hours once you click the verification email. Their guide also notes that if you do not see the confirmation email, you should check spam or junk immediately.

Friction points before you start

This is the stuff that actually wastes your time.

• Common names can produce multiple candidate records. Incogni explicitly warns about common-name matches.
• Confirmation emails may land in spam. They call this out directly.
• Some users may get a session-expired message. Incogni notes this can happen mid-process.
• Multiple records must be removed separately. Same email, separate removals.
• Listings may reappear later. Incogni recommends checking again because the site may re-index fresh public records.
• You may be blocked before you even start. That happened in my test environment via Cloudflare.

That last one is the big one.

The opt-out button is not the finish line. It is the start of a recurring hygiene task.

A better operating procedure for removal

Don’t just click through it and hope. Use a process.

1. Use a dedicated email inbox for removals. Not your primary inbox.
2. Search current and past cities/states. Old records love old location combos.
3. Document every matching listing in a spreadsheet. Site, URL, submission date, expected removal date, re-check date.
4. Confirm the email immediately. Don’t let the link rot.
5. Re-check after 72 hours. Then again after 30 days.
6. Set a recurring 90-day reminder. Because refresh cycles are real.
7. Repeat the process on adjacent brokers. TruePeopleSearch is rarely the only place your data lives.

Here’s a simple tracker format:

Another X post captured the exact reaction category users have when these tools disappear or change, people immediately reveal they were using them as lightweight background-check engines, which is exactly why I keep saying this category is risky when the stakes are high.

Now how the hell am I gonna run background checks on here

— shane hollander’s lawyer btw (@hollanovslawyer) Thu Apr 09 20:21:31 +0000 2026

Alternatives by job-to-be-done, not by affiliate payout

Most comparison posts on this topic are sludge. Ten tools. Zero judgment. Suspiciously identical “pros and cons.”

No thanks.

FastPeopleSearch vs TruePeopleSearch

In practice, these two are close cousins.

Both are strong for:

• quick name lookups
• fast reverse phone checks
• seeing more than you’d expect without paying

Both are weak on:

• trust-building UX
• privacy posture
• making the opt-out feel like a first-class experience

FastPeopleSearch’s opt-out page says: “Please carefully follow the directions below to opt-out of the sale of your information,” and asks for your name and email so it can send a link to complete the process.

My practical take:

• If TruePeopleSearch surfaces the record faster, use it.
• If it doesn’t, FastPeopleSearch is the next tab I open.
• I do not meaningfully trust either one more than the other.

They feel like the same category with slightly different paint.

Whitepages vs TruePeopleSearch

This one is easier.

TruePeopleSearch often surfaces more for free. Whitepages tends to feel more polished and less likely to send you into a messy ad maze.

That polish matters. Not because pretty interfaces are morally superior, but because clarity reduces accidental clicks and bullshit.

If I want a quick free hit, I’ll start with TruePeopleSearch.

If I want fewer cheap-feeling interactions, Whitepages is calmer.

Spokeo vs TruePeopleSearch

Spokeo is better if you are willing to pay for stitched records. Worse if your goal is simply “tell me who called me” without turning the lookup into a buying journey.

Spokeo’s homepage says it combines data from a “wide range of industry-leading data sources” into reports, and it leans hard on report-style outcomes. It also promises updates on purchased reports “for the lifetime of your Spokeo account” as the data refreshes.

That can be useful. It also comes with more upsell gravity.

So no, Spokeo is not simply “better.” That’s lazy.

It’s better for a different buyer.

When NinjaPear is the better alternative for professional/company research

I want to be explicit here because pretending these tools solve the same problem would be bullshit.

If you are trying to look up a consumer, a relative, a home address, or a personal phone number, NinjaPear is not the replacement. Wrong tool.

But if your real use case is actually one of these:

• researching a company executive before a sales call
• identifying a professional profile from a work email
• enriching a company account with employee count, company details, customers, and recent updates
• tracking company blog, X, and website changes for account intelligence

Then NinjaPear is the better lane because it is built for professional and company intelligence from publicly sourced data, not consumer people search.

Here is where it fits, plainly:

Source-backed examples from NinjaPear’s public materials:

• NinjaPear says its employee profiles are publicly sourced and include work history, education, and social presence.
• Customer Listing API shows customers, partners, and investors of a business.
• NinjaPear’s homepage says Company Details, Employee Count, and Company Updates cost 2 credits per call each.
• NinjaPear explicitly says it does not scrape the major professional social network for these endpoints and uses no social media scraping in its employee-profile positioning.

That distinction matters.

Consumer people-search tools answer: “Who is this person in a personal-record sense?”

NinjaPear answers: “What is happening around this company, this executive, this account, this market?”

Different jobs. Different data. Different ethics. Different workflows.

Who should use TruePeopleSearch, and who absolutely should not

This part is not complicated.

Good fit

• someone trying to identify a spam caller
• someone doing a one-off free lookup
• someone checking whether an old address or phone still ties to a person
• someone trying to reconnect with an old friend using partial info

For those use cases, true people search can be genuinely handy.

Bad fit

• hiring teams
• landlord / tenant screening
• compliance-sensitive research
• journalists or investigators needing high-confidence verification
• anyone confusing “free” with “low-risk” or “complete”

Let me say the quiet part out loud.

If the decision matters, this category is too messy to be your source of truth.

The data can be incomplete. Old. Merged weirdly. Missing context. Or just presented in a way that creates false confidence. That combination is dangerous.

The bigger lesson: free people-search engines are monetizing a tradeoff

This is the narrative turn most reviews avoid.

You are not paying cash for the lookup. That part is true.

But the service is still monetized. TruePeopleSearch’s own app description says ads can send you to paid services. So the product has to do two things at once:

1. be useful enough that you come back
2. expose and package enough personal data that the experience remains valuable and monetizable

That tradeoff is the product.

Not conspiracy fan fiction. Just incentives.

And once you see it that way, the category makes a lot more sense.

The reason a free reverse lookup can feel so useful is the same reason searching yourself can feel gross.

There is also a real difference between consumer people-search products and responsible B2B intelligence infrastructure. The former is built around aggregating personal records for broad lookup. The latter, done right, is built around publicly sourced professional and company data tied to clear business workflows.

That distinction matters more than ever.

FAQ

Is TruePeopleSearch legit?

Yes. It is a real people-search service with an official website and Android app. “Legit” does not mean low-risk or reliable enough for serious verification.

Is TruePeopleSearch really free?

Yes. The company’s Google Play listing says its content is “100% free.” That same listing also says the app contains ads and sponsored links that can send users to paid services.

Is TruePeopleSearch safe to use?

Safe for casual browsing? Usually. Safe as a source of truth for serious decisions? No. I would not use it for employment, tenant, legal, or compliance-sensitive screening.

How do I remove my info from TruePeopleSearch?

Go to truepeoplesearch.com/removal, enter your email and CAPTCHA, search your name plus city/state, open the matching listing, click Remove This Record, and confirm by email.

Can my info come back after removal?

Yes. Incogni’s 2025 guide explicitly says your info may reappear as public records refresh, which is why recurring re-checks matter.

Is there a TruePeopleSearch app?

Yes. There is an Android app listed on Google Play under TruePeopleSearch.com.

What are the best alternatives?

For casual consumer lookups: FastPeopleSearch, Whitepages, and Spokeo are the obvious alternatives. For professional or company intelligence: use something purpose-built, like NinjaPear.

Is NinjaPear an alternative to TruePeopleSearch?

Not for consumer people search. Yes for professional/company intelligence use cases like executive research, account enrichment, customer mapping, and company monitoring.

Final verdict

Here’s the clean recommendation matrix.

• Need a quick free lookup? Sure. TruePeopleSearch can help.
• Need accuracy you can rely on? No.
• Found your own record? Remove it now.
• Need B2B professional or company intelligence? Use a purpose-built platform like NinjaPear instead.

If you do one thing after reading this, don’t overthink it: search yourself on TruePeopleSearch today. If your record is there, start the opt-out process, document it, and set a 90-day reminder to check again. That’s the move.

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/
• X post by Kanika: https://x.com/KanikaBK/status/2043744028991336935
• X post by hollanovslawyer: https://x.com/hollanovslawyer/status/2042337130219807064
• 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 competitor intelligence, buy something built for company data. The expensive mistake is buying a bloated suite because the demo looked smart.

“You have to look at them all as directional or for entertainment only. All of them.”

Similarweb, how does it work when it comes to site visitors?
by u/[deleted] in bigseo

When I was running FluxoMetric, I learned very quickly that “all-in-one” usually means “half-useful across six tabs.” I burned ~$4K/mo at one point on software that made me feel informed while I was still blind to the only thing that mattered: what changed, who moved, and whether the move actually affected my market.

TL;DR

If you just want the shortest possible answer on competitor research tools, here it is.

That last row is the point. There is no true “best competitor research tool” because this is not one software category. It is five.

What most lists get wrong

Most lists call everything from Ahrefs to Crayon to Similarweb a competitor research tool. That is lazy taxonomy.

These tools do different jobs:

1. Keyword overlap: who ranks where, who owns what terms, where your content gaps are.
2. PPC intel: who bids on what, what ad copy survives, which terms look contested.
3. Traffic intel: directional market share, channels, geography, audience behavior.
4. Ongoing monitoring: pricing page edits, new landing pages, blog launches, product moves.
5. Company intelligence: customers, partners, investors, hiring shifts, relationship maps.

A CEO shopping for competitor research tools usually does not need one platform. They need one answer per job.

That is why so many teams overbuy. They think they are buying market intelligence. They are actually buying overlap, screenshots, and a Slack channel nobody reads.

The short answer

Here is the buying guide I would give a founder friend over coffee.

Best for keyword overlap

Ahrefs if you care about depth, backlink context, and living in the weeds.

Semrush if your team wants one broader suite and can tolerate some sprawl.

Ahrefs pricing currently starts at $129/mo for Lite, $249/mo for Standard, and $449/mo for Advanced on its public pricing page.

Semrush public pricing shows Pro at $139.95/mo, Guru at $249.95/mo, and Business at $499.95/mo via its pricing results and support docs. If you are not in the platform weekly, both can feel expensive fast.

“If you only dip in occasionally, it’s too expensive.”

Is Ahrefs still worth the price if you're not an agency?
by u/Other_Amphibian871 in WebsiteSEO

Best for PPC intel

SpyFu.

Not because it is perfect. Because the job is narrow and the price is sane. SpyFu public pricing shows Basic at $39/mo, Pro + AI at $59 for the first month then $119/mo, and Team at $249/mo.

If you mostly want ad history, basic competitor keyword overlap, and a cheap second opinion for paid search, it is better than its prestige level suggests.

Best for traffic intel

Similarweb, but only if you actually need traffic intel.

That caveat matters. Similarweb’s marketing packages page pushes you toward sales for business plans, and their own comparison page claims a full stack from $399/mo. Translation: this is easy to overbuy.

Best for monitoring

Visualping for straightforward page-level monitoring.

Visualping does one useful thing very well: check pages and tell you what changed. Their public materials put paid plans from roughly $10/mo, with business tiers above that, plus a free tier. Good. Cheap. But page-level.

Best for company intelligence

NinjaPear, if your question is not “who outranks us?” but “who buys from them, who they partner with, and what changed at the company level?”

That is a different job entirely. NinjaPear’s positioning is very explicit: customers, competitors, employees, updates, and usage-based pricing rather than giant seat bundles.

Types of competitor research

If you skip this section, you are probably going to buy the wrong thing.

Keyword overlap

This is classic SEO competitor work:

• Who ranks for the same terms
• Where you are losing share
• Which content gaps matter
• What backlinks or SERP features they own

Ahrefs and Semrush are built for this. Everything else is a compromise.

PPC overlap

Different job.

You want to know:

• Which keywords competitors appear on
• Which ad copy they keep running
• What landing pages they push repeatedly n- Where paid competition is getting hotter

SpyFu is the budget specialist here. Google Ads Auction Insights is still more truthful for your own auctions, but not useful for broad market snooping.

Traffic intel

Traffic intel is mostly model-based estimation. That means:

• useful for relative comparisons
• useful for trend direction
• dangerous when treated as audited truth

This is where Similarweb earns its keep, but also where buyers lie to themselves the most.

Ongoing monitoring

This is the “what changed since last week?” layer.

• pricing page edits
• new feature pages
• fresh blog posts
• social posts
• page launches, removals, copy shifts

Visualping handles the page-watch part. Broader monitoring needs broader plumbing.

Company intelligence

This is the missing layer in most competitor research tools roundups.

You care about:

• customers
• partners and platforms
• investors
• employee and leadership changes
• competitor maps
• account-level signals

SEO tools are weak here. They can tell you who ranks next to you. They cannot tell you who buys from your competitor or when a prospect account just changed stack.

The scorecard

I tested these tools the way an operator would, not the way a content farm would.

Questions I care about:

• Does the data help me make a decision this week?
• How many clicks until insight?
• Is the pricing sane for a small team?
• Does the monitoring produce signal or just noise?
• Are exports or APIs available without getting extorted?
• Is this useful to a CEO, not just a specialist?

Scoring criteria

Tools compared

My hot take is simple: the expensive enterprise CI platforms are often workflow theater unless you have a PMM or enablement function that will actually keep them alive.

Keyword overlap tools

If your real job is search overlap, stop pretending a generic CI suite is a substitute.

Ahrefs

Ahrefs is still the tool I trust most when the work is:

• backlink inspection
• content gap work
• SERP and ranking analysis
• deep SEO operator workflows

Its public pricing is clear, which I respect: Lite $129, Standard $249, Advanced $449. One included user on those plans, with extra seats costing more. No bullshit “request a quote” wall until enterprise.

What I like:

• cleaner than Semrush for focused SEO work
• strong backlink context
• better for people who already know what they are doing

What I do not like:

• expensive if you use it casually
• easier to justify for operators than founders
• API access is not really the reason most SMBs buy it

If you live in SEO every week, fine. If you log in twice a month, it is an expensive security blanket.

Semrush

Semrush is broader.

That can be good or bad. Good if one team wants SEO, some traffic intel, keyword gap work, and adjacent features in one place. Bad if you are paying for surface area you will never touch.

Public pricing is easy enough to verify:

• Pro: $139.95/mo
• Guru: $249.95/mo
• Business: $499.95/mo

What I like:

• broad workflow coverage
• decent competitive research tools in one account
• better option if you want one platform for one team

What I do not like:

• sprawl
• lots of tabs, not all of them equally sharp
• overkill for small companies with one narrow use case

SpyFu

SpyFu is the tool people underrate because it does not have the same brand halo.

It also knows what it is. That helps.

For $39/mo on Basic, you get a cheap way to inspect competitor ad history, keyword overlap, and basic domain comparisons. That is enough for a lot of PPC teams.

“SpyFu for the cost is far less expensive.”

SpyFu vs SEMRush for PPC?
by u/CyberSecurityGuy1989 in PPC

Now the caveat, because there is always one: PPC estimate data is still estimate data.

A sharp comment from the same thread said the only somewhat valuable part was the ad copy library. That is fair. If you treat SpyFu like a perfect x-ray of competitor budgets, you will be disappointed. If you treat it like cheap reconnaissance, it is excellent value.

Traffic intel tools

This is the part of the market where dashboards get prettier as the certainty gets lower.

Similarweb

Similarweb is the default answer for traffic intel because it has the strongest executive-facing product in this bucket.

Its business packages page is very obviously built for bigger buyers. Most pricing is routed to sales. Public claims elsewhere on the site reference $399/mo for a broader stack comparison. Either way, it is not cheap.

What it does well:

• directional traffic comparisons
• market/channel views
• geographic and audience splits
• benchmark-style reporting for execs and boards

What it does poorly:

• convincing people the numbers are exact
• preventing overbuying

“Long-time SimilarWeb Pro user here. For large websites (100k+ visitors per day), the data is very good on domain-level. The marketing channel split is wrong. But it is wrong the same way for everyone. So you can still use it to compare websites.”

Similarweb, how does it work when it comes to site visitors?
by u/[deleted] in bigseo

That is the healthiest way to use Similarweb. Directionally. Relative to peers. Not as gospel.

Most CEOs do not need it. They need one clean answer to “is this market moving?” not an expensive addiction to top-down traffic charts.

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
• sanity checking a market view

If you are a sub-$20M company and someone is trying to sell you Similarweb as a default purchase, I would push back hard.

SparkToro

SparkToro is not really a traffic estimation tool. It is an audience discovery tool.

This matters because sometimes your real question is not “how much traffic do they get?” It is “where does this audience pay attention?”

Search results show SparkToro pricing starting at $38/mo on a low-tier paid plan, with a free version as well. That makes it attractive for light audience work.

Use it when:

• you want podcasts, sites, creators, and accounts your audience follows
• you are planning distribution, not just spying on competitors
• you want source discovery more than traffic estimates

Do not use it as a fake Similarweb replacement. Wrong tool.

Monitoring tools

Monitoring is where most teams either save themselves or drown in low-grade noise.

Visualping

Visualping is the cleanest answer for page-level competitor monitoring.

You point it at:

• pricing pages
• feature pages
• comparison pages
• docs pages
• legal / policy pages

And it tells you what changed.

I like it because the mental model is simple. I dislike it because simple monitors become spam cannons when teams get greedy.

“We use Visualping on their pricing pages... Honestly, it’s easy to miss unless someone on the team is watching it on purpose.”

Has competitor pricing ever changed and hurt a deal because you didn't catch it?
by u/Jumpy_Specialist5483 in SaaS

My rule: monitor fewer pages, but monitor the pages that can actually change a deal.

Owler

Owler is fine for lightweight company alerts.

That sounds like a backhanded compliment because it is one.

If you want:

• easy company following
• basic news and updates
• less setup than enterprise CI platforms

it is useful. But the public pricing picture is murky now. Their site heavily funnels you toward demos and sales motions, which I never love for a relatively lightweight use case.

Good entry point. Shallow output.

Crayon / Klue

I am grouping these together because they solve a similar org problem:

• PMM teams
• sales enablement
• battlecards
• competitive workflow distribution

Their pricing is not publicly listed in a useful way. Both routes go toward sales. That usually means two things:

1. they are selling a program, not just software
2. they are expensive enough that small teams should be skeptical by default

And then there is the bigger issue.

A lot of competitive-intelligence software is workflow theater. If nobody updates the battlecards, you bought an expensive graveyard.

“I would honestly kill the 'monthly CI update.' Nobody has time for that.”

Why static battlecards are where competitor research goes to die
by u/Narrow_Back_6413 in ProductMarketing

That is not a tooling problem. That is an operating model problem.

NinjaPear

This is where I need to be precise so I do not insult your intelligence.

NinjaPear is not trying to be 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 / competitor / relationship context

That combination matters. A page diff without business context is just motion. Context turns motion into signal.

The homepage and docs are unusually clear about this: usage-based pricing, updates feeds, customer listings, competitor mapping, and API-first delivery.

Company intelligence tools

This is where most “best competitor research tools” articles fall flat on their face.

NinjaPear

If I care about business questions, I want business data.

The useful pieces on NinjaPear are:

• company updates
• customer lists
• competitor identification
• employees and profiles
• usage-based API access

The docs show public API costs like 2 credits for Company Details, Employee Count, and Company Updates. The customer listing endpoint is 1 credit per request + 2 credits per company returned, which is the kind of detail I wish more vendors published.

The customer listing view is the fastest illustration of why SEO-only competitor research is incomplete.

If you know who buys from a competitor, you can:

• prospect those accounts
• compare ecosystems
• spot overlap and whitespace
• build actual territory strategy

That is more useful to a B2B sales or CEO workflow than one more chart about estimated visits.

Owler

Owler gives you lightweight awareness.

That is not nothing. It is just not the same as relationship intelligence, account mapping, or fresh company change data. Useful for keeping tabs. Weak for deeper strategy.

Similarweb and others

Tools like Similarweb can tell you a lot about audience and traffic patterns. They 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?”

Those are different questions. Buy accordingly.

Free tools that still help

Not every stack needs to start with a $400 tab.

Free SEO checks

These are still useful:

• Wappalyzer extension for quick tech stack checks
• Google search operators for quick overlap checks
• free website traffic checkers for rough direction, not truth
• limited free versions of Ahrefs/Semrush adjacent tools

Wappalyzer’s paid plans jump quickly, $250/mo for Pro and $450/mo for Business, but the free account still gives 50 technology lookups per month. For quick technographic validation, that is plenty.

Free monitoring

Visualping’s free tier can cover a handful of critical pages if you are disciplined.

That discipline matters more than the tier.

Track:

• one pricing page
• one flagship product page
• one compare page
• one blog or changelog feed

Not 200 pages because you got excited on a Tuesday.

Free company research

Public company pages, press release searches, funding databases, and NinjaPear’s free developer tooling can all help before you commit to a bigger spend.

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 buying mistakes.

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 paid search matters
• add monitoring only if somebody actually owns it

If there is no owner, the alerts become wallpaper.

Product marketing / CI team

Buy:

• monitoring
• battlecard workflow if the team is real, not aspirational
• company intelligence layer

This is where Crayon, Klue, and NinjaPear start to make sense. But only if there is an actual operating cadence behind them.

B2B sales team

SEO tools alone are half-blind here.

You need:

• company changes
• relationship mapping
• customer lists
• account-level signals

This is why pure SEO tooling disappoints sales leaders. It answers the wrong question.

Where NinjaPear fits

I hate when vendors pretend to replace everything. So here is the 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 for teams that want to build on top

The product pages are clear on the value prop: customers, competitors, employees, company updates, and simple usage-based pricing.

What it is not

It is not a replacement for Ahrefs or Semrush if your job is:

• backlink analysis
• keyword clustering
• content gap research
• SERP-level SEO work

That is not fake humility. It is 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 relative benchmarking and trend direction. 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 + 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 whole article.

“Competitor research tools” is mostly a fake category. Real buying decisions happen one job at a time.

If you want the practical next step, use the stack builder at the top, then cut one tool from your shortlist before you buy anything. Most teams are not under-tooled. They are overbought. And if your real blind spot is company changes, customer overlap, and relationship mapping, take a look at NinjaPear’s company intelligence pages before you spend another month staring at directional traffic charts.

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 been the CEO signing the software bill. So I care less about feature bingo and a lot more about whether a tool creates signal or just creates work. My verdict on Visualping is simple: it’s good software for watching pages. I’d use it for pricing pages, job boards, docs, stock alerts, and policy pages. I would not use it as my main competitive intelligence system, and that’s where leadership teams screw this up.

“Using visualping, I can tell it wait 5 seconds for all the JS to load, then click on a bunch of elements, write my zip code and then check if it’s available.”

Got really annoyed with visualping.io last night and created my own ...
by u/maxupp in programming

That quote matters because it kills the lazy critique. Visualping is not a toy. It can wait for JS, click stuff, type into fields, and monitor the resulting state. The problem is different: people buy a page monitor and expect it to behave like an analyst.

Upfront: I’m a competitor

Yes, I lead GTM at NinjaPear. Yes, we have a product in this category, specifically Company Monitor, which tracks company updates across websites, blogs, and X. So I’m obviously not neutral.

Good.

Neutral is overrated when the person writing the review has never had to justify a tooling budget.

I’ve spent real money on this category for years. When I was running FluxoMetric, I burned ~$4K/month across monitoring and enrichment tools at one point, and half of them produced the same disease: more alerts, more tabs, more human review. So I’m not promising objectivity. I’m promising receipts, screenshots, and hard distinctions.

The 20-second verdict

Final verdict: Visualping is a strong page monitoring tool with a clean UX, useful visual diffs, enough dynamic-page support for non-trivial workflows, and real API/webhook options once you move into Business plans. My overall score is 3.1/5.

Use-case split: - Use it if your job is: “tell me when this page changes.” - Don’t use it as your main intel layer if your job is: “tell me what this company is doing.”

Use it for page alerts

Visualping is legitimately good for: - pricing pages - careers pages - docs and changelogs - policy and compliance pages - restocks and ticket drops - some authenticated dashboards and portals

That’s not a small list. Those are real jobs. If I needed a non-technical operator to monitor 20 pricing pages by this afternoon, Visualping would be on the shortlist.

Skip it for market intel

Competitive intelligence is not “a screenshot changed.” It is “this company added an enterprise security page, posted a hiring burst for solutions engineers, and shifted pricing copy in the same week.” Visualping can catch the first part. It does not natively give you the second and third in one coherent layer.

That difference sounds subtle. It isn’t. It’s the difference between seeing motion and understanding motion.

TL;DR

That table needs context, obviously.

If you are a CEO or head of Ops with a small team and public pages to watch, Visualping is still a very reasonable buy. If you are trying to reduce analyst labor across dozens or hundreds of companies, the category itself is the constraint.

What Visualping gets right

Setup is dead simple

This part they nailed.

The homepage still communicates the core workflow in about 5 seconds: enter URL, choose what matters, pick frequency, send alert, done. No jargon safari. No setup maze. That matters more than reviewers admit because half the battle in this category is getting someone to actually configure the damn thing.

On the live homepage, Visualping literally shows the flow in the hero: enter a page, click Go, choose alert criteria, set check cadence, send to an email, and start free monitoring. That’s smart product marketing because it mirrors the actual user job instead of vomiting 40 features into a hero section.

And yes, it’s polished. More polished than a lot of these tools.

Visual diffs are human-friendly

A lot of monitoring tools make sense only if you’re comfortable staring at HTML, selectors, or ugly text diffs. Visualping’s screenshot-first diffs are easier for non-technical teams to parse.

That is not a small UX preference. If your PMM, RevOps lead, or founder has to review the alert, highlighted screenshot diffs are much easier to scan than raw DOM churn. You see what moved. Fast.

This is also why Visualping is well-suited to executive workflows. CEOs do not want to inspect XPath. They want “what changed?” with enough visual context to decide whether it matters.

It handles tricky pages

This is the strongest pro-Visualping point I found in public user commentary.

“Using visualping, I can tell it wait 5 seconds for all the JS to load, then click on a bunch of elements, write my zip code and then check if it’s available.”

Got really annoyed with visualping.io last night and created my own ...
by u/maxupp in programming

That comment is from 2020, but the underlying point has held up. TechRadar also called out the “perform actions” feature for typing, clicking, and scrolling. And Visualping’s own 2026 article on password-protected pages explicitly documents two methods for login-wall monitoring:

1. Chrome extension, which captures your active browser session.
2. Pre-actions with element selector, where the crawler types, clicks, waits, and then monitors.

That means the honest answer is not “Visualping can’t handle advanced pages.” It can. The honest answer is “it can handle more than basic pages, but the more weirdness you add, the more operational caveats show up.”

Where it starts to suck

Change is not signal

This is my biggest issue with most Visualping reviews. They act like detecting a page change is the same thing as delivering intelligence.

It isn’t.

A page monitor tells you something moved. It does not reliably tell you: - whether the move matters commercially - whether it was one-off noise - how it connects to broader company behavior - whether you should do anything about it

Visualping clearly understands this, because their product and content now lean hard into AI summaries, AI alerts, and importance filtering. Their own help doc goes even further: the higher-end Solutions motion includes AI concierge service, custom data structure and output, starter packs, image change interpretation, and upgraded models for more precise change interpretation.

That tells you something important.

The monitor is easy. The interpretation is where budgets go to die.

Noise becomes labor

The subscription price is rarely the real bill.

The real bill is this: who on your team opens the alerts, checks whether they matter, deduplicates them mentally, writes down the useful ones, and ignores the garbage without missing something important?

That labor compounds fast.

I found one recent Reddit complaint from a builder who abandoned visual monitors for event tracking because the workflow was “too noisy,” specifically calling out false positives from pixel changes like ads and cookie banners when they only cared about date changes.

“False Positives: Visual monitors alert you when pixels change (e.g., an ad banner updates or a cookie popup appears). I only care if the actual date changes.”

I tried using Visualping to track event dates, but it was too messy. So ...
by u/rignaneseleo in SaaS

That is not me taking a cheap shot. That is just the category showing its natural failure mode.

When I was consulting in Austin, this was the pattern over and over: the team thought they had a monitoring problem, but they actually had a triage problem.

Website-only is a narrow lens

If your use case is “monitor this page,” website-only is fine.

If your use case is “monitor this company,” website-only is already incomplete.

Companies signal through: - website page edits - new pages appearing in a sitemap - blog posts - changelogs - X posts - hiring shifts - product naming changes - positioning changes across channels

Visualping is excellent at one slice of that. It is not the whole stack.

This is why I keep making the distinction between page monitoring and company monitoring. One is about diffs. The other is about interpreted updates across multiple surfaces.

Pricing: the real trap

Free gets you hooked

Public references on Visualping’s free plan vary by surface and date.

The Chrome Web Store listing still says the extension offers 62 checks/month free for the server service. TechRadar’s 2025 review says the free plan includes 150 checks/month and 5 pages. So if you’re trying to spreadsheet this like it’s fixed law, don’t. Public references vary by context, surface, and date.

That inconsistency is not some grand scandal. It just means you should verify the exact free limits on the live pricing page before budgeting around them.

What I would not do is assume the free tier tells you much about real team usage. It doesn’t. Free is how you learn the product. It is not how you operationalize a workflow.

Business is where workflows start

TechRadar reported these plan 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

I’m comfortable using those as public context because they are attributed and specific. But the bigger point is not the sticker price.

The bigger point is this: the moment you want Slack, Teams, Google Sheets, API, webhook, shared workflow, and team collaboration, you are no longer shopping a cheap side tool. You are shopping a workflow purchase.

Visualping’s own help doc says Business plans are for professionals who want to integrate changes “via our API, Webhook, Google Sheets, Slack, or MS Teams.” Their integrations page also says integrations are available in all Visualping for Business plans.

That’s reasonable. I’m not whining that a business product charges for business features.

I’m saying a lot of buyers mentally price Visualping like a light utility, then operationalize it like a system. That’s where disappointment starts.

Human review is the hidden cost

TechRadar also mentioned separate paid support add-ons ranging from $600/year to $3,000/year. Again, the support price is not my main objection.

My objection is that most reviews still miss the real budget line item: analyst time.

If you pay $100/month and save a team 6 hours, great purchase.

If you pay $100/month and create 8 hours of low-grade alert triage, congrats, you bought admin work with prettier screenshots.

That is the trap.

API and integrations reality

Integrations are solid

This is a legit strength.

Visualping’s integrations page explicitly lists: - Slack - Microsoft Teams - Google Chat - Zapier - Google Sheets - Lindy.ai - n8n - Webhooks - API - Discord

That is enough coverage for most normal workflows. If your team lives in Slack or Teams, or you want a webhook into your own system, Visualping is not lacking there.

And I like that the integrations page is straightforward instead of pretending every connector is some moon landing.

Programmatically, yes, it’s real

A lot of vendor sites say “API” and mean “one brittle endpoint and a prayer.”

Visualping looks more serious than that.

Their integrations page says you can programmatically create, update, and manage your Visualping jobs. Their March 2026 API article goes deeper and shows actual payloads for: - creating jobs with POST https://job.api.visualping.io/v2/jobs - setting interval in minutes like 5, 60, 1440 - narrowing monitoring to a specific selector with xpath - adding preactions for clicks and typing before monitoring - setting webhook notifications - pulling active jobs and recent changes - filtering for important changes via AI summaries and flags

That matters for ops-heavy teams. Once you get past ~30 monitors, dashboards start to become a pain in the ass. The API is how you stop doing repetitive hand setup.

Visualping’s own API article also makes a point I agree with: tracking 50 pages by hand is tedious, tracking 500 becomes a job in itself.

But they’re not the same as insight

A Slack alert about a page change is still just a page change.

I know that sounds obvious. It isn’t obvious in budget meetings.

Moving the alert into Slack, Sheets, Zapier, n8n, or your own app does not magically upgrade the information quality. It upgrades distribution. That can be useful. It is not the same as interpretation.

This is one of those moments where teams confuse integration maturity with intelligence maturity.

They are not the same thing.

Business-plan gating matters

Visualping is very explicit about this in its own help center.

The Business plans are for users who want to: - scale to more pages or higher frequency - collaborate in a central dashboard - organize pages with workspaces and labels - integrate via API, webhook, Google Sheets, Slack, or MS Teams

That’s the line that matters. Not because it’s unfair. Because it resets the buying math.

If you’re just watching a few public pages yourself, Personal might be enough.

If the changes have to flow into a real team process, you are in Business territory whether you like it or not.

Bot blocking, login walls, and edge cases

This was the missing section in the earlier draft, and it matters.

Because the minute someone says “we monitor pages behind login” or “we can click and type,” the next questions are obvious: - What about bot detection? - What about CAPTCHA? - What about 2FA? - What about SSO? - What about pages behind a login wall?

The short answer is: Visualping is more capable than a basic public-page monitor, but it is not magic, and it is not a stealth scraping stack.

Behind login walls, yes, with caveats

Visualping’s February 2026 guide on password-protected pages is unusually direct. It says they support two approaches:

That is exactly the kind of clarity I want from a vendor.

The Chrome extension approach works by capturing your active browser session. If you can see the page in Chrome, Visualping can often monitor it. 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: extension method, yes - basic username/password: pre-actions or extension, yes - complex SPA auth flows: extension is more likely than pre-actions - expiring sessions: expect re-auth pain

This is real capability. Also real friction.

Bot detection, no, they are not pretending to be bulletproof

This is where I give Visualping credit for honesty.

In their own login-monitoring guide, they say: “Some sites detect and block automated access.” Their suggested workaround is to use the Chrome extension in Device mode because it uses your real browser. They also say pre-actions do not work with CAPTCHA-protected logins.

Even more importantly, Visualping’s own scraping-related content says their system will never attempt to solve CAPTCHAs or circumvent systems designed to protect sites from unwanted crawling.

Good.

That is the right answer.

If a vendor claims they glide through Cloudflare, Akamai, login friction, and CAPTCHA without tradeoffs, one of two things is happening: 1. they are being sloppy with the truth, or 2. they are quietly drifting into a very different product category.

Visualping is a monitoring tool. Not a black-ops anti-bot framework.

Device mode vs server mode, the real tradeoff

This is the practical operator view.

Device mode is better when: - the target site hates bots - auth is messy - you need your real browser fingerprint and session - you can tolerate checks only running while your machine and Chrome are active

Server mode is better when: - you want background monitoring - sessions do not expire too fast - you need checks to run when your laptop is closed - the site is not especially hostile to automated access

That is not just a product detail. It is an ownership detail.

If your workflow depends on Device mode, somebody now owns “keep the browser alive and logged in.” Usually that somebody is the poor bastard in RevOps.

Advanced use cases, where it’s genuinely useful

Visualping is more capable than the average buyer realizes. Based on TechRadar, Visualping’s own docs, and their API article, the real advanced use cases include:

• monitoring a page after a click, type, scroll, or wait action
• monitoring specific elements instead of the whole page
• checking password-protected pages
• setting custom AI importance definitions for what counts as meaningful
• sending alerts via webhook, not just email
• spinning up hundreds of monitors programmatically through the API
• tracking specific keywords rather than every visual change
• routing change data into Slack, Sheets, or internal systems

That is a legit feature surface.

Where I still draw the line is this: advanced page monitoring is still page monitoring.

Is there an RSS feed?

This is where the answer gets slightly annoying.

I found strong public evidence for email, Slack, Teams, Google Sheets, Discord, Google Chat, webhooks, Zapier, n8n, and the API. I did not find first-party evidence that Visualping exposes a native RSS feed output for alerts.

Could you build an RSS-like workflow yourself? Yes.

If you control the webhook destination, you can push changes into your own feed generator, database, or digest system. But that is not the same as “Visualping has native RSS output.” Based on the evidence I found, I would not market that as a native product feature without a direct doc proving it.

This is one of the cleanest distinctions with NinjaPear Company Monitor, by the way. Our monitor is designed around an RSS-consumable company-updates feed from day one. Visualping is more native to screenshot diffs and notification routing.

My scorecard

Here’s my blunt scorecard for Visualping.

And here’s the broader comparison table using one consistent operator rubric.

Yes, that makes Visualping look middling.

That does not mean it’s bad.

It means the tool 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 is more appealing if you’re a tinkerer or power user who wants tighter control. Its public pricing has long skewed better for technical users who want more checks, more control, and faster intervals per dollar.

That’s a stronger price-to-control profile than Visualping for technical users. But I would still put Visualping in front of a non-technical founder before I put Distill there.

Visualping wins on polish. Distill wins on knobs.

Visualping vs changedetection

changedetection.io is for people who would rather pay with setup time than subscription money.

The open-source tradeoff is brutally simple: you get far more control, but you also own the plumbing. If you’re comfortable with Docker, selectors, browser steps, API usage, and the occasional broken job, it is absurdly cost-effective.

“There also exists this project https://github.com/dgtlmoon/changedetection.io which is self-hosted...”

Got really annoyed with visualping.io last night and created my own ...
by u/maxupp in programming

That’s the actual tradeoff in one comment. Visualping is easier. changedetection.io is cheaper and more flexible if you’re willing to own the mess.

Visualping vs NinjaPear Monitor

I’m going to say this as plainly as possible.

• 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’s the line.

Our product exists because I got tired of teams building competitive workflows on top of page diffs alone. A pricing page update matters more when it lands next to a new product page, a hiring push, and a CEO post. That’s why we built feeds for company-level updates instead of just highlighted screenshots.

If you only need page diffs, don’t overbuy. I mean that.

What Reddit and X got right

Reddit on dynamic pages

The best short proof of Visualping’s capability is still that couch availability quote. It shows the product can wait for JS, click elements, type inputs, and monitor the resulting state.

That’s real functionality, not brochure fluff.

Reddit on DIY alternatives

Reddit also gets something else right: technical buyers compare Visualping with self-hosted options almost immediately.

That is exactly what should happen.

If your team is comfortable with Docker, browser automation, selectors, and owning a box, changedetection.io deserves serious consideration. If your team is not, the cost of “free” rises quickly the first time something breaks on a Sunday.

X on competitor monitoring

I found one practitioner post that I actually believe because it describes a sane, limited use case instead of pretending page alerts are a full intel stack:

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. Practical. No nonsense.

And then there’s this X post about sitemap monitoring:

/sitemap.xml every website has one. it's a complete list of every page, including ones not yet publicly announced new product pages, new pricing tiers, new integration pages, new career sections, all appear in the sitemap before the press release monitor competitor sitemaps with visualping . io they have no idea they're leaking their roadmap

— Aryan Mahajan (@aryanXmahajan) Mar 26, 2026

This is smart. Also incomplete.

Monitoring a sitemap is a great tactic. I’ve used variants of it myself. But again, it tells you something new exists. It does not, by itself, tell you whether the company is making a meaningful move across the rest of its surface area.

Screenshots and proof

Homepage hero

Already captured. It shows the thing I like most about Visualping: the product promise is clear fast.

Integrations proof

This is the cleanest source for workflow routing and API positioning.

Help-doc proof

The help article is the strongest proof point for workflow gating and higher-end service layers. It explicitly says Business plans are for teams integrating via API, webhook, Google Sheets, Slack, or MS Teams. It also spells out that Solutions includes AI concierge, custom outputs, and support for more complex requirements.

Evidence table

Who should buy it

Buy Visualping if

Buy Visualping if all or most of this is true: - you’re a solo operator or a small team - you need simple page alerts, not broader company intelligence - you care about visual diffs more than structured output - most targets are public web pages - you want something a non-technical person can set up in one sitting - you may occasionally need login-wall monitoring, but you understand the caveats

I’d also buy it if I were a founder who wanted 10 to 50 high-value pages monitored quickly without turning the project into engineering work.

Skip Visualping if

Skip it, or at least don’t make it your main system, if this sounds more like your reality: - you need structured company intelligence - you need website + blog + X + new-page coverage together - you are trying to reduce analyst labor, not merely detect page movement - you say “competitive intelligence” but what you really mean is “tell me what matters” - your targets are consistently behind hostile bot defenses or CAPTCHA-heavy auth flows - you expect highlighted screenshots to substitute for interpretation

That last one gets teams in trouble all the time.

My final take

Visualping is good software. I mean that.

It is easy to set up, visually clear, and more capable on dynamic pages and login-gated pages than a lot of people realize. For page alerts, especially pricing pages, docs, jobs, stock alerts, policy pages, and some authenticated portals, it’s a very reasonable answer.

But good software gets misbought all the time.

If your job is “alert me when this page changes,” Visualping is worth paying for.

If your job is “tell me what this company is doing,” it’s the wrong layer of the stack.

That distinction sounds small. It isn’t. It’s the difference between getting notified and actually knowing what matters.

If you’re still deciding, build a brutally honest buyer sheet with four columns: pages to watch, who reviews alerts, what happens when a change fires, and whether the target pages sit behind auth or bot friction. If that exercise makes the workflow look heavier than you expected, you probably don’t need more page monitors. You need better signal design.

And if your real need is company-level monitoring across web, blog, and X, with an RSS-style feed you can actually consume, look at NinjaPear’s Company Monitor instead of forcing a page watcher to do a market-intel job.

If I were a CEO buying a business intelligence platform in 2026, I would not start with a feature grid. I’d start with this: Power BI is still the safest default, Tableau still wins on visual analysis, Looker only makes sense if you already have a real data team, Qlik is better than the market gives it credit for, Sigma is the modern one, ThoughtSpot is the best bet if search-first analytics matters, and most companies are overpaying for capabilities they will never operationalize. The license is not the real cost. The cleanup job six months later is.

“I'd avoid Looker, as a current admin of both that and Tableau. Looker is way more expensive and much more complicated to use (LookML is its own language). If you have on-prem servers it's also difficult to set up connections.”

Shifting from Tableau to either Looker or PowerBI
by u/theungod in BusinessIntelligence

That comment is blunt. Good. Buying a BI platform should be blunt.

I’ve been on the hook for this decision from both sides. At FluxoMetric, I burned ~$4K a month on analytics tools that looked smart in the demo and turned into maintenance hobbies in production. Later, running Meyer Growth Labs in Austin, I inherited half-built BI stacks where the dashboard looked polished and the data model underneath was basically a crime scene.

So this is not another lazy top-15 roundup written by someone who has never had to explain a five-figure renewal to finance. This is the buying guide I’d hand a CEO before they let RevOps, IT, finance, and one very polished AE drag them into a 3-year contract.

TL;DR

Here’s the fast comparison table for the main business intelligence platform shortlist.

My executive summary:

• Best default buy: Power BI
• Best visuals: Tableau
• Best governed metrics: Looker
• Most underrated: Qlik
• Best modern UX: Sigma
• Best search-first pick: ThoughtSpot
• Best fast-start dashboard stack: Domo
• Best cheap/open source option: Metabase
• Best SMB value: Zoho Analytics
• Best external company intelligence layer for BI: NinjaPear

Why most BI advice sucks

Most business intelligence platform advice on page one is written by one of three people:

1. The vendor.
2. An affiliate writer who has never owned a renewal.
3. Somebody who thinks a dashboard screenshot counts as implementation experience.

That’s why the advice is so bloodless. Nobody says the obvious part out loud: switching BI tools is usually a rebuild, not a migration. Nobody says the finance fight matters. Nobody says your semantic layer can rot faster than your dashboards. Nobody says the wrong tool will quietly create trust debt inside the company.

When I was running FluxoMetric, the most expensive analytics mistake I made was not buying the wrong software. It was buying software before we had earned the complexity. That mistake cost me ~9 months, a few contractors, and enough monthly SaaS burn to make me physically ill every time I opened the bank dashboard.

And here’s the bigger miss. Most BI comparisons only compare the dashboard layer. They ignore the fact that a business intelligence platform without outside-world data is often just internal reporting with nicer fonts.

If your CEO wants to know which competitors changed messaging, which prospect accounts just added 12 AI roles, which customers overlap with a rival, or which companies quietly changed pricing, that is not magically created by Tableau or Power BI. You need external data vendors for that. I’ll get to that later because it’s the part most listicles completely whiff.

How I scored them

I scored these platforms the way operators actually live with them, not how they demo.

No points for a slick homepage. No points for AI glitter. No points for “vision.” I care about what happens after month 4, after the first reorg, after the original dashboard builder quits, and after your CFO asks why you’re paying enterprise prices for 19 dashboards nobody trusts.

The nine things that matter

I used nine dimensions for every business intelligence platform here:

1. Visualization quality
2. Self-service ease
3. Governance / semantic consistency
4. Scalability
5. Pricing sanity
6. Developer friendliness
7. Stability / admin sanity
8. Data freshness support
9. Fit for external intelligence workflows

The star ratings below reflect operating reality, not demo quality.

The fast answer

Best default buy

Power BI

If you need the safest answer, this is still it. Microsoft ecosystem gravity is real. Procurement likes it. Finance likes the list price more than most alternatives. Most companies can get to “good enough” fast.

The catch: Power BI also creates a ton of “good enough” analytics debt. DAX spaghetti. Model sprawl. Workarounds piled on workarounds. I’ve seen more mediocre analytics estates built in Power BI than any other tool, partly because it’s so easy to buy.

Best for visual analysis

Tableau

Still the prettiest gun in the room. If your analysts need exploratory work, presentation-heavy analysis, and nuanced visual control, Tableau still deserves real respect.

But a lot of companies are paying luxury prices for charts they barely need.

Best for governed metrics

Looker

If nobody trusts the numbers, and you have the warehouse plus analytics engineering muscle to back it up, Looker is still one of the strongest metric-governance bets on the market.

If your company is still half spreadsheet, half wishful thinking, do not touch it.

Most underrated pick

Qlik

Qlik suffers from familiarity bias. Buyers forget it because it doesn’t dominate mindshare like Power BI or Tableau. That’s dumb. Its associative model is still legit, and power users consistently respect the backend.

Best modern challenger

Sigma

Sigma is the tool I see modern warehouse-native teams warm to fastest. The spreadsheet metaphor lowers fear. Business users click around like they’re in Sheets. Data teams don’t have to pretend CSV chaos is a strategy.

Best for search-first analytics

ThoughtSpot

If your adoption problem is that nobody wants to learn dashboard navigation, ThoughtSpot earns a lane of its own. The whole point is question-first analytics.

Still, search UX is not a substitute for governed data. Garbage in, natural-language garbage out.

Best if you want fast setup

Domo

When speed matters, Domo keeps showing up because it has a lot of prebuilt connectors and a more packaged feel than many competitors.

That speed can be a gift. Or a trap. Depends whether your team is skipping data discipline to get a dashboard into the board deck by Friday.

Best open-source / cheap option

Metabase

If you do not need an enterprise monster, Metabase is often the sober answer. Cheap, simple, open source, and good enough for a surprising number of internal dashboard use cases.

Best budget SMB option

Zoho Analytics

This one gets ignored by enterprise-heavy reviews, which is a mistake. For SMBs that need useful reporting without Tableau money, Zoho Analytics is a real option.

Power BI review

My score: ~3.9/5

Why it keeps winning

Power BI keeps winning because the buying process is easier than the implementation reality.

A few reasons:

• Cheap relative to the field
• Microsoft ecosystem gravity
• Familiar enough that procurement feels safe
• Sometimes already politically bundled

Microsoft’s public pricing currently lists Power BI Pro at $14/user/month and Microsoft’s pricing update confirms Premium Per User at $24/user/month. That matters because list price is often what gets Power BI onto the shortlist in the first place.

Where it gets messy

Power BI’s dirty secret is not that it’s bad. It’s that it makes it very easy to create analytics debt that looks productive.

The biggest pain points I see:

• DAX debt
• Model sprawl
• Sharing and licensing quirks
• Too many workarounds for “basic” asks once complexity rises

“You gotta be really careful. You can solve today's problems with PowerBI, but this can easily snowball to technical debt, solving things quickly today will make issues tomorrow. Each model becomes its own bird's nest to untangle if some metric or underlying application changes.”

Power BI is so powerful you don't even need an ETL?
by u/deleted in BusinessIntelligence

“If your tables change often then you probably need an abstraction layer like ‘Views’... avoid using dax or power query if you can. Powerbi is slow when working with large data sets.”

PowerBI limitations and best practices
by u/deleted in BusinessIntelligence

And here’s the tweet I wish more buyers would internalize before they get hypnotized by AI-demo theater:

"AI is killing Power BI and Tableau"... no it's not. No one wants your boutique custom dashboard interface. They want something reliable, with data refreshes that work, that they can share with colleagues, that have admin, viewing, and collaboration features.

— Alex Freberg (@Alex_TheAnalyst) April 8, 2026

That is exactly right. Reliability beats novelty in BI, every damn time.

And this second X post is smaller, but it captures something I’m seeing a lot more in mature teams: AI and code are speeding up the visual layer, not magically replacing modeling discipline.

Version 0.22.0 of the Power BI agentic development plugins have a new skill for DAX ... I recommend using the pbir-cli in an iterative way where you specify the requirements and formatting that you want. Avoid using open-ended, subjective prompts "make a good report" ... The tool doesn't think or design for you; it lets you focus on that part while it takes care of the formatting and tasks!

— Kurt Buhler (@kurtbuhler) April 10, 2026

Exactly. Better tooling, same need for judgment.

Pricing reality

Verified public pricing:

• Power BI Pro: $14/user/month
• Power BI Premium Per User: $24/user/month

I removed the Power BI pricing image because it was failing to load in publication. Better to keep the verified numbers and Microsoft source than ship a broken asset.

Tableau review

My score: ~3.7/5

Why analysts still love it

Tableau still feels like it was built by people who give a damn about analysis as a craft.

That shows up in exploratory visual work, presentation quality, and the sheer amount of control analysts get.

“Tableau is still ‘the’ industry standard, as far as I can tell. I have been using it for 6 years now.”

Is Tableau still alive?
by u/deleted in tableau

“Tableau. But Power BI is a close second!”

What is your favorite data visualization BI tool?
by u/Zealousideal-Kale532 in BusinessIntelligence

That sentiment persists for a reason. Tableau still has better taste than most of the field.

Why finance hates the invoice

The problem is simple: role-based pricing adds up fast.

Tableau’s public pricing page lists:

• Standard Edition: Viewer $15, Explorer $42, Creator $75, billed annually
• Enterprise Edition: Viewer $35, Explorer $70, Creator $115, billed annually

That means a mid-sized org can create a very serious annual bill before it has solved governance, semantic consistency, or adoption.

Pricing reality

Verified public pricing from Tableau’s pricing page:

• Standard Viewer: $15/user/month billed annually
• Standard Explorer: $42/user/month billed annually
• Standard Creator: $75/user/month billed annually
• Enterprise Viewer: $35/user/month billed annually
• Enterprise Explorer: $70/user/month billed annually
• Enterprise Creator: $115/user/month billed annually

For a 10 Creator, 20 Explorer, 100 Viewer deployment on Standard, you’re at $34,080/year before add-ons or services.

Tableau pricing page, captured from https://www.tableau.com/pricing. Public list pricing shows Standard and Enterprise starting prices.

Second Tableau pricing capture from the same public page. This view shows the role-based licensing detail, which is exactly where the invoice starts to bite.

Looker review

My score: ~4.1/5 for the right team, ~2.8/5 for the wrong one

Why serious data teams still buy it

LookML is both the reason to buy Looker and the tax you pay forever.

If your company has a real warehouse, dbt or equivalent modeling discipline, analytics engineers who can think in systems, and real governance pain, then Looker can be fantastic.

Google Cloud’s public package docs confirm:

• Standard includes 10 Standard Users, 2 Developer Users, 1,000 query-based API calls/month, and 1,000 admin API calls/month
• Enterprise includes 100,000 query-based API calls/month and 10,000 admin API calls/month
• Google’s pricing page also says each platform comes with ten standard users and two developer users included

That API quota detail matters more than most vendor pages admit, especially if you plan to operationalize external enrichment workflows.

Why most teams should not touch it

Looker is not overpriced because it’s bad. It’s overpriced for teams that have not earned the right to need it.

If your current stack is spreadsheets, a half-maintained warehouse, one analyst doing SQL plus stakeholder therapy, and no agreement on metric definitions, then Looker is not your savior.

“Everything has to be put into a data warehouse first, which Looker directly connects to and queries. You have to know LookML, which is another language, to do the modeling and metric creation. Looker usually is the more expensive option.”

What are the main limitations of Looker compared to Tableau / Power BI?
by u/Mountain-Car-1515 in BusinessIntelligence

Packaging reality

Verified public package details from Google Cloud:

• Standard: 10 standard users, 2 developer users, 1,000 query-based API calls/month, 1,000 admin API calls/month, max 50 users
• Enterprise: 10 standard users, 2 developer users, 100,000 query-based API calls/month, 10,000 admin API calls/month, no max users
• Embed: 500,000 query-based API calls/month and 100,000 admin API calls/month

Google Cloud Looker pricing page, captured from https://cloud.google.com/looker/pricing. No public dollar pricing, but Google does publish edition entitlements, included users, and API quotas.

Qlik review

My score: ~3.9/5

Why Qlik deserves more respect

Qlik is the tool buyers forget until a serious BI practitioner reminds them it exists.

Its associative model is still useful. Its backend and data handling get real respect from technical users. And it consistently outperforms its market buzz.

“As a Tableau Developer for more than 6 years, QlikView impressed me. The amount of control it gives to the creator is next level. The pixel-perfect formatting, the ability to write extensive data manipulation scripts and the associative engine.”

Which BI tools impressed you the most (excluding usual suspects)?
by u/theoriginalmantooth in BusinessIntelligence

Why it still loses deals

Qlik loses for boring reasons: lower mindshare, fewer default champions, and pricing framed by capacity rather than simple per-seat math.

Pricing reality

Qlik’s public pricing page is refreshingly explicit:

• Starter: $300/month
• Standard: $825/month
• Premium: $2,750/month
• Enterprise: contact sales

Qlik Cloud Analytics pricing page, captured from https://www.qlik.com/us/pricing. Starter, Standard, Premium, then enterprise quote. Nice and blunt.

Second Qlik capture from the same public pricing page. This view makes the capacity framing clearer than most vendor pricing pages do.

Sigma review

My score: ~4.0/5

Why Sigma feels fresh

Sigma is one of the few BI tools that immediately makes business users feel less stupid.

The spreadsheet metaphor lowers fear, reduces the training burden, and works especially well for warehouse-native teams.

“Sigma”

“Sigma is awesome”

What newer or lesser-known BI tools have actually impressed you?
by u/Kimber976 in BusinessIntelligence

“My job recently did a POC with Sigma. I loved the product. Significantly easier to do complicated calculations compared to Power BI. I prefer the browser based first BI tools.”

Anyone with experience with Sigma BI?
by u/Ok-Working3200 in BusinessIntelligence

The tradeoff nobody mentions

Sigma does not rescue bad modeling. It just makes good modeling easier to explore.

Pricing is still custom, which I find annoying, and you still pay downstream warehouse costs. That second part gets ignored in a lot of buyer guides written by people who apparently have never seen a Snowflake bill.

ThoughtSpot review

My score: ~3.8/5

Why it matters

ThoughtSpot matters because most BI adoption dies from friction, not lack of capability. People want to ask a question and get an answer, not learn some cursed folder taxonomy.

Where it breaks

Natural-language search does not absolve you of data quality. If the source tables are inconsistent, then the search bar just gives people a faster route to confident nonsense.

If search-first analytics matters, it deserves a look. If your source layer is a mess, it deserves a hard pass.

Domo review

My score: ~3.6/5

Why people buy it

Domo gets bought because speed is intoxicating. It has a lot of connectors, it feels packaged, and it can get dashboards in front of execs fast.

“Dashboards have been a lot smoother lately with tools I've tried and Domo in particular makes connecting different data sources pretty easy.”

What newer or lesser-known BI tools have actually impressed you?
by u/Kimber976 in BusinessIntelligence

“In any BI tool, you’ll need to ensure your data is clean, integrated, and curated... Domo has one-click integrations with most CRMs, GA4 and data warehouses like Snowflake. So if you want fastest, find the one with the integrations you need.”

Which analytics platform is the fastest setup for a non-technical team?
by u/Appropriateman1 in BusinessIntelligence

Why I’m cautious

I get wary when speed is the primary buying argument. Domo often gets chosen by teams that want results before they have decided what the source of truth is, how metrics are defined, and who actually governs shared data.

That is a good way to impress the board in month one and hate yourself in month nine.

Sisense review

My score: ~3.6/5

Where Sisense is strong

Sisense still matters because embedded analytics is a different buying motion. If you need customer-facing dashboards or product analytics inside software, Sisense deserves a look.

Where it gets tricky

If you are not embedding analytics into a product, I usually find stronger defaults elsewhere. Sisense is more relevant when the BI output is part of your product, not just part of your internal reporting stack.

Metabase review

My score: ~3.4/5

Why I like it

Metabase has a quality a lot of enterprise BI tools lost years ago: restraint.

It is simple, cheap, useful, and often more than enough for internal dashboards. Metabase’s pricing page makes the split pretty clear:

• Open Source: free
• Starter: $100/month plus $5 per user monthly, or $1080/year plus $65 per user yearly
• Pro: $575/month plus $12 per user monthly, or $6210/year plus $130 per user yearly
• Enterprise: custom pricing, starts at $20k/year

“Metabase is open source and great to use.”

What is the best free BI/dashboarding tool?
by u/financialthrowaw2020 in dataengineering

Where it stops being enough

Metabase starts to strain when you need heavier enterprise governance, broader semantic control, polished executive presentation, or advanced distribution workflows.

Metabase pricing page, captured from https://www.metabase.com/pricing/. Public pricing is refreshingly explicit, including the point where Enterprise starts at $20k/year.

Zoho Analytics review

My score: ~3.6/5

Why it makes sense

Zoho Analytics gets ignored because the BI conversation is weirdly prestige-driven. But plenty of SMBs do not need prestige. They need a tool that works and doesn’t make the CFO swear.

From the public pricing page I captured, Zoho Analytics lists annual cloud pricing in SGD as:

• Basic: S$32/month billed annually
• Standard: S$64/month billed annually
• Premium: S$160/month billed annually
• Enterprise: S$632/month billed annually

The page also shows row and user limits, which is exactly the kind of useful detail a buyer needs and most “best BI tool” articles skip.

Why it is not the answer for everyone

At the top end, Zoho Analytics is not where I’d go for elite governance, scale, or modern warehouse-native sophistication. But for SMBs, it’s a sane option.

Zoho Analytics pricing page, captured from https://www.zoho.com/analytics/pricing.html. Screenshot shows public annual cloud pricing and plan limits.

Oracle and Cognos quick take

Oracle Analytics

Still relevant in Oracle-heavy environments. Usually not what I’d call pleasant.

If you are already deep in Oracle procurement, identity, and data infrastructure, it can be rational. Fresh greenfield buyers should be honest with themselves about how much vendor-estate gravity is doing the work here.

IBM Cognos

Still alive. Still more likely to be inherited than loved.

Modern mid-market teams should not rush toward Cognos unless there is an estate reason. Most fresh evaluations have friendlier options.

SAP and MicroStrategy quick take

SAP BusinessObjects

Still around in SAP-heavy shops. Often more “we already have it” than “we chose it fresh.”

MicroStrategy / Strategy

Powerful, enterprise-y, and often more than smaller teams need.

And here’s a useful contrast from X, even though it comes from the vendor side. The complaint it names is real: fragmented BI stacks and inconsistent definitions are usually the actual problem, not whether the home page says “AI” enough times.

Most organizations are still dealing with fragmented BI stacks, inconsistent definitions, and rising infrastructure costs. The result is slower insights, duplicated work, and missed opportunities. Strategy’s semantic layer, Mosaic, changes that by standardizing metrics, reducing tool sprawl, and creating a governed foundation for analytics and AI.

— Strategy (@MicroStrategy) April 8, 2026

Serious product for serious enterprise estates. Not where I’d start most mid-market CEOs.

BI data vendors worth adding

This is where most business intelligence platform buyers screw it up. They buy a dashboard tool and think they bought business intelligence.

No. They bought a way to analyze data they already have.

Why BI buyers get this wrong

A BI platform tells you what happened inside your company. But a CEO often needs answers about what changed outside the company:

• competitor launches
• account expansion signals
• customer overlap with rivals
• org changes
• pricing moves
• new hires
• funding
• intent and buying context

Your BI layer does not create that data. A data vendor does.

Without an external layer, many BI rollouts are just internal reporting cosplay.

The vendor categories

I’d break the market into buckets like this:

• Company intelligence: NinjaPear, ZoomInfo, Crunchbase
• Sales data / prospecting: Apollo, Cognism, Lead411
• ABM / intent: 6sense, Demandbase
• Data plumbing / orchestration: Clay
• Firmographic / technographic context: BuiltWith, Similarweb

Quick takes by vendor

NinjaPear

NinjaPear is the one I’d look at when the job is fresh company relationship intelligence plus change monitoring, not just contact lists.

The product is API-first and built around turning a company domain into things like customers, investors, partners, competitors, employee profiles, company details, employee count, and company updates.

The docs show official Python and JavaScript libraries, bearer-token auth, a backward-compatibility guarantee, a rate limit of 300 requests/minute for paid accounts, and 30 to 60 second response expectations on API endpoints. That makes it unusually workable as a BI data layer, not just a browser-only research tool.

ZoomInfo

Scale and brand gravity. Often expensive. Worth it if you need classic enterprise sales intelligence.

My issue is simple: too many teams buy the whole cathedral and only use one chapel.

Apollo

Cheaper and more accessible than ZoomInfo. Popular with startups. Good prospecting tool. Not a full BI layer by itself.

Crunchbase

Good for funding and investor context. Helpful, not sufficient.

6sense / Demandbase

Useful when you want intent plus ABM workflows, not just static company records.

Clay

Great as an orchestration layer. Not your source of truth by itself.

How NinjaPear fits your BI stack

The simple version

A BI platform tells you what happened inside your company. NinjaPear helps tell you what changed outside it.

That’s the real gap.

What data from NinjaPear can feed BI dashboards

From NinjaPear’s homepage, docs, and product pages, the useful BI inputs are obvious:

• customer listing data for account mapping and competitor-customer overlap dashboards
• competitor listing data for market map dashboards
• company updates data for change-monitoring dashboards
• employee / person profile data for org-change tracking and account intelligence
• company details and employee count for enrichment and segmentation

The docs also surface details BI teams actually care about:

• official JS and Python libraries
• bearer-token auth
• backward compatibility guarantees
• rate limits up to 300 requests/minute
• endpoint response expectations of 30 to 60 seconds
• explicit credit costs on endpoints like company details, employee count, company updates, and customer listing

That last one matters. I like knowing what an external data pull will cost before I wire it into a dashboard refresh workflow.

Example workflows

Power BI + NinjaPear

Use NinjaPear API outputs as a scheduled data source into Power BI for competitor and customer monitoring dashboards.

Build things like:

• competitor-customer overlap dashboards
• account expansion watchlists
• company-update alert boards
• territory prioritization by external signals

Tableau + NinjaPear

Use company relationship data to build overlap maps and segment heatmaps.

Tableau’s visual polish matters when the goal is to present market structure cleanly to execs or the board.

Looker + NinjaPear

Model external company intelligence in the warehouse, then layer governed views across customer overlap, competitor movement, and headcount changes.

This pairing makes the most sense when you already have a strong warehouse-first operating model.

Sigma + NinjaPear

Let RevOps or finance users explore relationship data in a spreadsheet-like interface.

That is a very nice combo for teams who want external company context without turning every question into a Jira ticket.

Why this section matters

This is not a forced plug. It solves a real gap. Most BI tools are strong at internal reporting and weak at market intelligence ingestion unless you add an outside data layer.

NinjaPear API
  -> warehouse or connector layer
  -> modeled tables / semantic layer
  -> Power BI / Tableau / Looker / Sigma dashboard

Example fields worth modeling:

• customers
• competitors
• employee_count
• company_updates
• person_profile

NinjaPear homepage, captured from https://nubela.co/. This is the cleanest quick visual I found of the product’s customers, competitors, and employees data model.

NinjaPear Company Monitor page, captured from https://nubela.co/company-monitor. This matters because outside-world business intelligence is not a slogan, it is an actual monitored feed of company changes.

NinjaPear Employee API page, captured from https://nubela.co/employee-api. Publicly sourced person-profile data is useful when you want BI dashboards to include org changes, exec mapping, and account intelligence.

Side-by-side scorecard

BI platform comparison table

Data vendor comparison table

Costs nobody warns you about

Migration rebuild costs

Switching BI tools is often a rebuild, not a migration.

This Reddit line about moving from Tableau to Power BI made me laugh because it’s painfully true:

“Power BI and then just blame Microsoft for all the problems that come from ‘migrating’ because you get to rebuild everything.”

Shifting from Tableau to either Looker or PowerBI
by u/staatsclaas in BusinessIntelligence

Budget for rebuild, retraining, validation, and political fallout. Not just licenses.

Semantic layer upkeep

If nobody owns metric definitions, your BI problem is not a dashboard problem. It’s a trust problem.

This is why Looker can be worth it for the right org, and why Power BI can quietly turn into definition chaos for the wrong one.

Dashboard sprawl

Everyone builds. Nobody deletes. Then nobody trusts anything.

I’ve seen companies with 400+ dashboards and no clear answer to which 20 actually drive decisions. That isn’t scale. That’s hoarding.

Warehouse spillover

A cheap BI tool on top of expensive warehouse queries is not cheap.

Sigma and Looker buyers need to hear this especially clearly. Warehouse-native is great until nobody is watching query cost, caching behavior, or model efficiency.

Training and adoption

The best tool on paper dies if nobody uses it.

ThoughtSpot can help adoption. Sigma can help adoption. Tableau can hurt adoption if the org mainly needs KPI consumption, not exploration. Power BI often wins on familiarity. Context matters more than ideology.

Procurement lock-in

Enterprise BI contracts love annual commitments, vague overages, and packaging complexity that gets worse as deployments grow.

This is why I prefer public pricing where it exists. At least it gives you an anchor before the weirdness starts.

What I’d buy by company type

Tiny startup

Usually, do not buy an enterprise BI platform just because a demo made you feel underdressed.

• Best default: Metabase or Power BI
• If warehouse-native: Sigma
• If you mostly need outside market data: pair a lightweight BI layer with NinjaPear

A 12-person startup buying Looker to feel legit is one of the funniest bad decisions in software.

10 to 50 person SaaS team

• Best default: Power BI
• Best modern warehouse option: Sigma
• Best if visual storytelling matters: Tableau
• Add NinjaPear if sales or strategy needs competitor/customer intelligence

Mid-market ops team

• Default: Power BI
• Smarter shortlist: Power BI, Qlik, Sigma
• If governance pain is real: Looker
• If embedded or external dashboards matter: Sisense or Domo

Enterprise with governance pain

• Looker or Qlik deserve a serious look
• Power BI works if the org can actually govern it
• Tableau is not a governance shortcut
• Oracle, Cognos, and SAP stay relevant if you are already deep in those estates
• Layer NinjaPear in when executive dashboards need outside-world company intelligence

Final verdict

Here’s my final answer if you’re buying a business intelligence platform in 2026.

• Best default buy: Power BI
• Best visuals: Tableau
• Best for governed metrics: Looker
• Most underrated: Qlik
• Best modern UX: Sigma
• Best for search-first analytics: ThoughtSpot
• Best fast-start executive dashboard option: Domo
• Best open-source budget choice: Metabase
• Best SMB value choice: Zoho Analytics
• Best external company intelligence layer for BI dashboards: NinjaPear

The best business intelligence platform is not the one with the slickest demo. It’s the one your team can still trust, afford, and operate 18 months later.

And if you want actual business intelligence instead of internal reporting cosplay, feed it better outside-world data.

If you’re in shortlist mode right now, do one practical thing next: run the calculator above, pick three tools max, and test them against your real seat mix, real data maturity, and one external-intelligence use case. If that outside-world piece matters, start with NinjaPear as the data layer and see what your dashboards can finally tell you that they couldn’t before.

If you want the blunt answer, here it is: TruePeopleSearch is the best free-first way to lookup a person by basic consumer data, Social Catfish is better when you're trying to verify whether someone is real, Searchbug is better when you need denser public-record style detail, Whitepages is the familiar mainstream option with a bigger free-to-paid split, and NinjaPear Employee API is the right tool when "lookup person" really means professional profile lookup from a work email or company context. The mistake is assuming one tool does all of that well. It doesn't.

That quote nails the entire lookup person SERP. Most pages aren't helping you find the right record. They're helping you enter a search, watch fake progress bars, and then pay for a report that still needs checking.

TL;DR

If you just want the shortest honest answer for lookup person, use this table.

My actual operator summary:

• Name or phone and you want a free first pass: start with TruePeopleSearch.
• Photo, username, email, or romance-scam vibes: start with Social Catfish.
• You want denser U.S. people-record detail and don't mind paying per search: use Searchbug.
• You know the Whitepages brand and want broad U.S. coverage: fine, but expect free previews and paid depth.
• You have a work email or company context: stop forcing consumer tools to do a B2B job, use NinjaPear.

Skip the teaser funnels

The first thing to understand about lookup person workflows is that many top-ranking sites are not educational pages. They're search boxes with marketing wrapped around them.

Whitepages is at least pretty explicit about what it covers. On its people search page, it says it scans public records for more than 250 million U.S. adults and splits data into free and premium tiers. That's useful because you know the game up front.

Social Catfish is also pretty clear on the model. It says you can start a search for free and preview potential matches, but paid plans may be required to unlock full reports. Fine. At least that's honest.

What pisses people off is the theater. Not the pricing. The theater.

That's why this page is organized by input and job, not by whoever bought the nicest landing page.

Here are two real pages I checked while researching this piece:

Whitepages shows the standard broad people-search interface: name field, location field, then a clean split between people search, reverse phone, and reverse address.

NinjaPear's employee page is a different species entirely. It's not trying to find your neighbor from an old cell number. It's built for professional context: work email, employer, role, structured work history.

I also tried to visually inspect Social Catfish and Searchbug in-browser. Both threw bot/security walls in this environment, which is itself worth noting because it affects how easy it is to inspect flows without committing. The browser only surfaced Cloudflare challenge pages for Social Catfish and a block page for Searchbug, even though their text content was still scrapable.

Start with your input

This is the main reframe. The right lookup person workflow depends on what you already know.

If all I have is a phone number, I'm not starting with name search. That's backwards. If I have a work email, I'm definitely not starting with Whitepages. Also backwards.

Name only

Name-only lookup is the easiest way to waste 20 minutes on the wrong John Smith.

Start with these narrowing fields before you pay for anything:

• city or last known city
• age band
• relative's name
• old address
• employer
• school

Whitepages says its free people search can show full name, age range, city/state, limited current and past addresses, landline phone numbers, limited relatives, current job title and employer details, and property ownership status. That's enough to narrow a list, not enough to trust blindly.

TruePeopleSearch is still my favorite free-first pass here because it tends to surface enough connective tissue fast: current and past addresses, relatives, associates, and phone numbers. But free people search is still a narrowing tool, not gospel.

Phone only

Phone-only lookup is better than most people think, but only if you account for recycled numbers.

A phone number is often more unique than a name. That's the good news. The bad news is carrier reassignment screws with certainty, especially if the number is old or the person churns through prepaid lines.

One Reddit thread on finding an old acquaintance put it plainly: the old number may be your best shot, but if they dropped it 8 years ago, you may be out of luck. Harsh, but true.

Reverse phone workflow I trust:

1. run a free-first reverse phone search
2. see whether the result gives you a person plus location history
3. verify with one more source, public web results, voicemail name, or social profile

If the stakes are money or safety, move from a reverse phone directory to a verification workflow, not just a prettier reverse phone page.

Email only

Email lookup splits into personal email and work email. These are completely different jobs.

If it's a Gmail, Yahoo, Outlook, or weird custom inbox used in dating/scam contexts, Social Catfish is usually the better first move because it supports email as one of its primary inputs and is built around identity verification. It explicitly supports search by name, phone, email, photo, username, or address.

If it's a work email, like jane@company.com, stop using consumer people-search tools. That input is professional context gold.

Username only

For scam checks, username often beats name.

Why? Because scammers, creators, sellers, and weird internet lurkers reuse handles. Same handle on X, Instagram, Reddit, TikTok, old forums, marketplace profiles. One exact-match username can collapse a fake identity faster than a full-name search ever will.

Start with exact-match queries:

• "username"
• site:x.com "username"
• site:instagram.com "username"
• site:reddit.com "username"
• site:tiktok.com "username"

Then compare avatar reuse, bio phrasing, location claims, and timeline consistency. A handle match is a pivot, not proof.

Photo only

Photo-only lookup is the easiest way to fool yourself.

Use reverse image search as a pivot, not as identity proof. Social Catfish is useful here because it supports image-based searching, but even then I treat image hits as the start of the investigation, not the end.

And yes, there are user complaints here too.

That doesn't mean Social Catfish is useless. It means image search is noisy. Which it is, everywhere.

Work email only

This is where most lookup person articles completely miss the plot.

If you have a work email, you're not trying to find a cousin who moved to Tulsa in 2018. You're usually trying to identify a professional accurately, with role and company context attached.

NinjaPear's Person Profile endpoint is built exactly for this. The employee API page says the strongest input is work email, and the pricing starts at 3 credits per lookup. The launch post documented 10/10 work email tests with 100% accuracy, versus 9/10 for name + company and 7/10 for role + company.

That's a different class of problem than consumer people search.

Best tool by job

A lot of "best lookup person" content lies by pretending there is one winner. There isn't.

Best free-first pick

Winner: TruePeopleSearch

If I want to lookup a person by name, phone, or address in the U.S. without pulling out a card, this is where I start.

Why it wins:

• genuinely free-first
• good for current/past addresses
• useful relative and associate clues
• reverse phone is fast
• enough detail to narrow before paying elsewhere

What it is not:

• a final source of truth
• a compliance tool
• immune to stale records

A Reddit commenter in r/onions called TruePeopleSearch a completely free web broker and recommended it as the obvious clear-web place to start. That's pretty much the right mental model.

Best scam-check pick

Winner: Social Catfish

When the job is "is this person real?" rather than "show me every public record tied to this human," Social Catfish is the better fit.

Its homepage says it supports name, phone, email, photo, username, or address, scans 200+ trusted sources, and is used for online dating safety, background verification, and reconnecting with people.

I would not use it as my only source of truth. I would use it as the fastest way to tie multiple scam-heavy inputs together.

Best deep-record pick

Winner: Searchbug

Searchbug is the tool I recommend when you know exactly what you need and don't mind paying for a denser record pull.

Its people finder page is refreshingly specific:

• $1.95 per search
• no charge if information is not found
• results can include aliases, current address, 3-year address history, all known phone numbers, age or DOB, relatives, and email address if known
• background reports can add criminal records, bankruptcies, liens, judgments, property records, licenses, and associated businesses

That's not sexy marketing. Good. I trust boring specifics more than sexy promises.

Best professional lookup pick

Winner: NinjaPear Person Profile Endpoint

When lookup person really means professional profile lookup from a work email, a name plus employer, or a role plus company, NinjaPear is the right tool.

What it returns from public sources is the part I care about:

• structured work history
• education
• bio
• city/country
• personal website
• X handle and X profile when found
• public profile picture when found

Consumer people-search sites usually blob this stuff together badly, if they include it at all.

Where Whitepages fits

Whitepages is still useful because of its breadth and familiarity.

Its people search page says it covers 250M+ U.S. adults, aggregates from public records, court filings, utility records, and premium data partners, and gets 30M+ monthly users. The free tier gives you a partial read. The paid tier gives you the rest.

It's not my first pick for every lookup person workflow. But it's still a credible mainstream option, especially when you want a big U.S. directory and you understand the free-to-premium split going in.

What these tools are really selling

They're not selling magic. They're selling aggregation.

Data sources

Whitepages is pretty explicit here. It says it aggregates from public records, court filings, utility records, and premium data partners.

Searchbug lists public records, phone books, vital records, real estate records, magazine subscriptions, voter registration, and proprietary sources.

Social Catfish says it scans 200+ trusted sources, including social networks, public records, and online databases.

NinjaPear says it aggregates professional data from company websites, press releases, public filings, open directories, and more, and that it does not scrape professional social networks.

Different inputs. Different source graphs. Different failure modes.

Why they get things wrong

People-search tools get things wrong for very boring reasons.

Not AI reasons. Not conspiracy reasons. Database reasons.

The biggest ones:

• stale addresses
• common-name collisions
• household blending
• recycled phone numbers
• outdated job info
• inferred relatives that aren't really relevant

One Reddit comment in a dating thread said TruePeopleSearch had the person's age wrong by 2 years. Another commenter replied that this stuff doesn't go away and leads to misinformation. Exactly.

That is why I never trust one source alone when the stakes are higher than curiosity.

Why free means partial

Free lookup person tools are usually not free because the company loves you. They're free because the teaser gets you to the paid layer.

Whitepages says the free tier includes:

• name
• age range
• city/state
• limited current and past addresses
• landline phone numbers
• limited relatives
• current job title and employer details
• property ownership status

Then premium adds:

• full phone numbers and email addresses
• exact age and DOB
• complete address history
• full relatives and associates
• detailed property records
• background check access

Social Catfish says the same thing in plainer words: start a search for free and preview potential matches, then pay for full reports.

So yes, free usually means partial. That's not a scandal. The scammy part is pretending the preview is the same thing as the result.

The most effective lookup workflow

This is the part most articles should have started with.

Reconnect with someone

If you're trying to find an old friend, classmate, former coworker, or relative, I would do this:

1. start with TruePeopleSearch or Whitepages free people search
2. narrow by city, age range, relatives, and old address
3. confirm against social profiles, alumni pages, or county/property records

If you buy anything too early, you're usually paying to expand the wrong candidate list.

Verify someone online

If the job is scam prevention, not reunion nostalgia, switch gears.

I use this order:

1. Social Catfish with the strongest input, email, phone, username, or photo
2. public web search for consistency, same handle, same face, same bio, same city
3. manual cross-check of timelines, claimed employer, age, and platform age

This is where multi-input tools earn their keep.

Lookup a professional

Professional lookup is its own branch.

Best input order:

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

If you have work context, use NinjaPear. Its launch benchmarks were honest enough to publish the misses: 100% on work email, 90% on name+company, 70% on role+company, with p50 uncached response time of 23.1s. I like when a vendor admits the weaker path instead of pretending all modes are equal.

Find your own exposed data

Do this against yourself once. Seriously.

Search your:

• full name + city
• current and old phone numbers
• current and old addresses
• personal emails
• usernames

Then start opt-outs. Whitepages, Social Catfish, Searchbug, TruePeopleSearch. More on that later.

Make a serious legal decision

Hard stop.

If you are making a decision about hiring, housing, credit, insurance, or employment screening, generic lookup person tools are not your toolset.

Use a compliant screening vendor. Get consent. Follow adverse-action rules. Talk to counsel if you operate at scale.

A consumer people search report is not a regulated background-check workflow, no matter how dramatic the PDF looks.

Use NinjaPear for work context

This section is practical, not promotional.

Because if your lookup person job is actually B2B profile resolution, the workflow really is different.

By work email

This is the cleanest path.

NinjaPear's employee API page literally labels work email as Best accuracy. Directly resolves the person from their corporate email. The launch post backed that up with 10/10 profiles found, 100% accuracy in its published work-email test set.

That's why I keep saying work email is not just another input. It's the input.

By name and employer

This is the second-best path when you know the person's company but not the email.

The launch post reported 9/10 found with 90% accuracy. It also admitted the miss was a very common name at a large company. Again, I like the honesty.

Common names break lookup systems because context gets diluted. That's not a NinjaPear-specific problem. That's a human-identity problem.

By role and company

This is the messy branch.

Useful? Yes.

Clean? Not always.

NinjaPear reported 7/10 found with 70% accuracy for role + company. The misses were either too-generic roles like "Software Engineer" at Google or obscure companies with limited public presence.

That lines up with reality. "CTO at a 70-person startup" is much easier than "software engineer at Google."

What NinjaPear returns

Based on the employee API page and launch example, here's the useful response pattern.

The Patrick Collison example on the page shows:

• full_name: Patrick Collison
• bio: Co-founder and CEO of Stripe
• country: IE
• city: Limerick
• x_handle: patrickc
• personal_website: patrickcollison.com
• work_experience: Stripe + prior role
• education: MIT

That is much closer to enrichment-grade JSON than people-search-directory sludge.

Remove yourself from these sites

This is the adjacent intent a lot of readers actually need after they lookup a person once and realize, "holy shit, I'm in here too."

Track your opt-outs

Make a sheet. Don't wing it.

Use columns like:

• site
• opt-out URL
• date submitted
• listing URL
• verification required
• follow-up date
• status

That is the whole "opt-out tracker" lead magnet idea from the plan, and it's genuinely useful because records come back.

Start with the biggest sites

Here are the main opt-out paths for sites mentioned in this article.

Whitepages also appears to require more involved verification in some cases. Several guides and user comments mention phone verification. That's annoying, but not unusual in this category.

Why your data comes back

Because the site you removed yourself from is often not the original source.

The upstream source might be:

• county/property records
• utility data
• credit-header style brokers
• voter files where lawful
• subscription data
• another broker who resold it again

One r/privacy thread on Whitepages had a top reply saying if you've ever signed up for home internet, cell plans, a credit card, or had a background check, your information has likely been sold or passed between brokers. That is the ugly, boring engine under this whole market.

That is why opt-out is maintenance, not a one-time cleanse.

FAQ

Can I lookup a person for free?

Yes, sometimes. TruePeopleSearch is the best free-first option for U.S. consumer data. Whitepages also gives partial free results. But free usually means limited fields, older data, or teaser previews.

What's the most accurate person lookup tool?

There isn't one universal winner. For free-first consumer lookup, I start with TruePeopleSearch. For scam verification, Social Catfish is stronger. For professional lookup by work email or employer context, NinjaPear is the most precise fit.

Can I find someone by phone number only?

Often, yes. Reverse phone lookup can work well, especially with recent numbers. But recycled-number risk is real, so always verify with another source before acting on it.

Is Social Catfish worth it?

If your job is verifying whether someone online is real, yes, it can be worth it. If you expect a flawless public-record dossier from a single photo search, no. That's the wrong expectation.

Is Whitepages free?

Partly. Whitepages offers a free tier with limited result fields and a premium tier with fuller details. Its pricing page says Premium Contact Info starts at $5.99/month.

Can I lookup a professional by work email?

Yes. This is exactly where NinjaPear fits. Its Person Profile endpoint takes a work email and returns structured professional fields like work history, education, location, public X profile, and personal website when found.

Can I use people-search sites for hiring or tenant screening?

No. Not if you want to stay on the right side of the law. For hiring, housing, credit, insurance, or similar regulated use, use an FCRA-compliant screening provider, not generic people-search sites.

My final take

Most lookup person advice fails because it asks the wrong question. Not "what's the best site?" The real question is what input do you have, and what are you trying to prove?

If you want a cheap, fast consumer first pass, start with TruePeopleSearch. If you're trying to verify an online identity, start with Social Catfish. If you want denser public-record style detail, Searchbug is a better fit than a lot of prettier brands. If you want broad mainstream coverage, Whitepages is still fine. And if you have work context, a work email, a company, or a role, stop pretending this is a consumer people-search problem and use NinjaPear.

If you want a useful next step, build yourself a tiny operator kit: one search-operator cheat sheet, one official-source verification matrix, and one opt-out tracker. That alone will save you more time than another "instant background report" ever will.

The wrong company logo api choice looks cheap on day one, then quietly ends up in your onboarding flow, CRM rows, alerts, emails, and dashboards, right before the provider changes terms or disappears.

That is why this category is more annoying than it looks. The question is not just which logo API works. The question is which one you can ship this week without creating dumb migration debt six months from now.

I’ve bought enough small infrastructure tools to know how this goes. When I was running FluxoMetric, the painful pattern was always the same: a tiny utility looked harmless, then it spread across the product, then it became a real bill or a real dependency. A company logo api is exactly that kind of trap.

TL;DR

If you are in a rush, use this:

• Use NinjaPear if your job is basically domain -> logo and PNG is enough.
• Use Logo.dev if you need SVG, dark mode, retina control, or a Clearbit-style migration path.
• Use Brandfetch if logos are only one part of a larger brand-data problem.
• Do not build around Clearbit because it is retired.

TL;DR summary comparison table

Summary comparison table with star ratings

Most teams do not need to pay for a company logo API

This category gets overcomplicated fast.

If your product needs to display a company logo, you usually do not need “brand intelligence.” You need an endpoint that works, does not clutter your UI with attribution, and will not become a migration headache later.

My bias, upfront

I am biased toward boring infrastructure. Good. Boring infrastructure is usually the right answer.

At FluxoMetric, I spent too much money on small tools that looked harmless. A few hundred bucks here. A few hundred there. Six months later, it was a stupid SaaS bill for things we barely touched. A company logo api is tailor-made for that mistake.

The only 5 things that actually matter

Ignore the landing page gloss. I would score these five things:

1. Cost
2. Attribution requirements
3. Rate limits and burst behavior
4. Asset flexibility
5. Vendor risk

That’s it.

If a vendor page spends more time showing pretty logos than explaining limits, terms, and output formats, I get suspicious.

Quick answer: which free company logo API should you pick in 2026?

Here is the blunt version.

My blunt recommendations by use case

• Use NinjaPear if you need the cheapest sane answer and your use case is just domain -> logo.
• Use Logo.dev if you need SVG, dark-mode variants, retina controls, or the cleanest Clearbit replacement path.
• Use Brandfetch if you need logos plus colors, icons, symbols, fonts, or broader brand metadata.
• Do not build around Clearbit because retired infrastructure is not infrastructure.

For most buyers, the answer is still NinjaPear. Not because it has the richest feature set. Because it does not try to sell you a richer feature set than you need.

Free logo API comparison table: NinjaPear vs Logo.dev vs Brandfetch vs Clearbit (RIP)

This is where the category gets practical.

Pricing, rate limits, attribution, and output formats

That NinjaPear number matters more than people think. 300 requests/minute works out to ~12.96M requests/month if you annualize it over a 30-day month. That is well above Logo.dev’s public 500K, 1M, and 5M plan caps.

Now, be an adult about this. Monthly-equivalent math is not the same thing as a contractual monthly allowance. Burst limits and monthly caps are different constraints. But if you want a raw contrast table, the contrast is brutal.

A quick note on Logo.dev pricing: the brief referenced $280/year for Startup and $1,260/year for Pro. Their public pricing page I checked showed $400/year and $1,800/year on annual billing. I’m using the live public numbers because otherwise this turns into fiction.

What those limits actually mean in production

Docs are one thing. Production is another.

• If you are building an internal tool, CRM, admin dashboard, notifications UI, or account list, NinjaPear’s free posture is very hard to beat.
• If attribution is unacceptable in your UI, Logo.dev’s free tier stops being free in any meaningful sense.
• If your use case is simple and you still buy a richer asset platform, that is not sophistication. That is waste.
• Brandfetch is impressive, but once you care about fonts, symbols, icons, and colors, you are solving a broader brand-data problem, not just a logo problem.

That last point matters. A lot.

Why Clearbit’s shutdown changed this entire company logo api category

A logo API seems trivial until it spreads across your product.

One engineer adds it to onboarding. Then sales wants it in the CRM. Then support wants it in inbox rows. Then product adds it to notifications. Suddenly that “small utility” is real infrastructure.

A logo API is trivial until it becomes infrastructure

I have seen this happen more than once.

It starts with an <img> tag. It ends with a migration ticket nobody budgeted for.

That is why the buying question is not “which demo looks best?” It is “which provider solves the boring problem cleanly without becoming roadmap debt later?”

The cautionary screenshot every buyer should see

Here is the screenshot every buyer should look at before choosing a free provider.

And here is the line that matters:

“After December 1, 2025, logo.clearbit.com stops working permanently.”

That one sentence explains the whole trust problem in this category.

If you had Clearbit wired into your product, the shutdown was not an abstract risk. It was a very real pain in the ass.

That quote is useful context. It also does not mean every team should pay for the replacement.

NinjaPear review: the free default I’d start with

I lead GTM at NinjaPear, so yes, I have a point of view here. I am not pretending otherwise.

What I like

NinjaPear’s company logo API does the core job most buyers actually need: domain in, logo out.

The public page is plain about the offer:

• Free forever
• 300 requests per minute
• ~12.96M requests/month equivalent if you annualize that throughput
• No monthly fee
• No attribution required
• PNG output

That is a good product decision because it stays in its lane.

The request shape is also simple:

curl -X GET \
  "https://nubela.co/api/v1/company/logo?website=https://stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  --output stripe-logo.png

You can wire that into an app in minutes.

What I don’t like

It is not trying to be a rich brand asset platform. That is good for focus, but it is still a limit.

If you need SVG, multiple themes, symbols, or deeper asset control, this is not the same class of tool. It is a blunt instrument, and I mean that as praise.

Best for

• Internal tools
• CRM enrichment
• Startup dashboards
• Notification and inbox UIs
• MVPs where shipping matters more than design perfectionism

My honest take

If your use case is boring, NinjaPear is better precisely because it stays boring.

And yes, I think the 300 req/min versus Logo.dev’s 500K, 1M, and 5M monthly caps is a bigger selling point than most buyers realize. For simple logo jobs, that volume headroom is kind of ridiculous for a free tool.

Logo.dev review: excellent, but most teams are buying polish they don’t need

I like Logo.dev. I just do not think every buyer needs to pay for it.

What I like

Logo.dev has clear product focus. It also has the most obvious migration path after Clearbit’s shutdown.

Its public pricing and docs make the pitch clear:

• SVG support
• dark mode and theme options
• retina and size controls
• ticker and brand search products
• cleaner frontend ergonomics for customer-facing apps

That is real value if your frontend team actually cares about rendering details.

What I don’t like

The free plan requiring attribution is annoying.

I’ll say it plainly: if I have to add your attribution to my public UI to keep free access, that is not free. That is visual debt. Their docs are explicit that the attribution link must be on a public production site and pass referrer data. For apps behind login, they suggest putting it on a public marketing page or about page.

That is a reasonable trade from their side. It is still a trade.

Pricing is also reasonable for a paid tool, but many teams are still solving a $0 problem with a $400 or $1,800 answer.

Best for

• Teams migrating from Clearbit and wanting the least-friction replacement
• Customer-facing SaaS where SVG or theme control truly matters
• Products where polish is part of the product value

My honest take

Logo.dev is good. I just think a lot of teams buying it are solving a $0 problem with a $400 to $1,800 answer.

Brandfetch review: rich as hell, but often overkill for simple logo use cases

Brandfetch solves a broader problem than many buyers think.

What I like

Brandfetch is stronger when logos are only one part of the job.

Their pricing page positions the free Logo API as the easy way to embed logos in your app, while the broader product gives you access to much deeper brand attributes. Their docs publish concrete limits too: 500,000 requests per month as a fair-use soft limit, plus 1,000 requests every 5 minutes per IP and 2,400 requests every 5 minutes per customer.

That specificity is useful.

What I don’t like

The deeper you go into Brandfetch, the clearer it becomes this is not just a logo utility.

That is fine if you need it. It is overkill if you do not.

If your product only needs a logo next to a company name, the ROI gets muddy fast.

Best for

• Fintech transaction enrichment
• Brand-aware UIs
• Products where icons, colors, fonts, and symbols are part of the real UX

My honest take

If all you need is a logo, Brandfetch can feel like bringing a marching band to a two-person meeting.

The buying criteria most pages gloss over

This is the section I wish more comparison pages wrote honestly.

Attribution is not a footnote

For some teams, attribution is fine.

For others, it is product debt. If you are building customer-facing software and care about a clean UI, “free with attribution” is not free. You are paying with clutter and exceptions.

Monthly caps vs burst throughput

People mix these up all the time.

• Monthly caps matter for embedded dashboards, account lists, and repeated daily usage.
• Throughput limits matter for imports, backfills, and bursty jobs.

NinjaPear publishes 300 req/min. That is ~12.96M requests/month if you convert the rate into a 30-day equivalent. Brandfetch publishes 500K/month fair use, plus 1,000 per 5 min per IP and 2,400 per 5 min per customer. Logo.dev pricing is mostly framed around 500K, 1M, and 5M monthly request caps.

Those are different constraints. Read them that way.

Caching policy is half the product

Ask these questions before you integrate anything:

• Can I cache locally?
• For how long?
• What happens if terms change?
• What happens if the endpoint disappears?
• How painful is migration?

People treat caching like fine print. It is not. It is half the economics.

Migration risk is real

Clearbit proved this category can go from “freebie” to roadmap debt fast.

A tiny endpoint gets embedded into your product before anyone notices. Then it vanishes, and suddenly five teams care.

Hands-on benchmark plan and proprietary proof

I am not going to fake a giant benchmark. If I did not run it, I will not pretend I did.

What I can do is give you a benchmark plan that your team can run in an afternoon.

25-domain benchmark sheet

Here is the test set I would use across mainstream SaaS, public companies, fintechs, obscure startups, and annoying edge cases:

For each provider, record:

• success or failure
• output format
• visible correctness
• fallback quality
• implementation friction

If I were handing this to an engineer, I would also add cacheability and rate-limit behavior under concurrency.

Side-by-side output gallery

You do not need marketing copy when your eyes can do the work.

Test these 8 domains first:

• stripe.com
• shopify.com
• figma.com
• notion.so
• brex.com
• ramp.com
• granola.ai
• levels.fyi

Then compare:

• Does the logo render?
• Is it correct?
• Is the fallback usable?
• Does the endpoint need auth, attribution, or extra parameters to look good?

That gallery will cut through a lot of nonsense.

Real implementation snippets

Here are the minimum viable integrations.

NinjaPear

curl -X GET \
  "https://nubela.co/api/v1/company/logo?website=https://stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  --output stripe-logo.png

Logo.dev

<img src="https://img.logo.dev/stripe.com?token=YOUR_PUBLIC_TOKEN&size=128" alt="Stripe logo" />

If you are migrating from Clearbit-style URLs, that is part of the appeal.

Brandfetch

curl -X GET \
  "https://cdn.brandfetch.io/stripe.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

If you are evaluating Brandfetch seriously, do not stop at the logo endpoint. Test the broader brand attributes too. That is where the value either becomes obvious or unnecessary.

Cost scenario table

This is where overbuying gets obvious.

If the use case is simple, the cost delta gets hard to justify very quickly.

Who should use what in 2026

This part is simpler than people make it.

Use NinjaPear if...

• You want the cheapest sane answer
• You just need domain -> logo
• PNG is enough
• You hate attribution clutter
• You are building internal tools, CRMs, alerts, dashboards, or MVPs

Use Logo.dev if...

• You need SVG or theme-aware rendering
• You want the smoothest Clearbit replacement path
• Your product team genuinely cares about polish
• Those frontend details are real requirements, not nice-to-have fantasies

Use Brandfetch if...

• You want brand colors, fonts, symbols, icons, or richer brand context
• Your product is more brand surface than utility surface
• You are doing transaction enrichment or brand-aware UX

Do not do something dumb just because a landing page looked pretty

Most teams are overthinking this.

If you need a logo next to a company name, stop shopping like you are licensing Getty Images. Use the free option that solves the boring problem cleanly. Pay only when your product truly needs the extra control.

If you want the default answer, here it is one last time: start with NinjaPear for a boring company logo api use case, move to Logo.dev only when SVG, theme variants, or Clearbit migration pressure are real, and use Brandfetch when logos are just one part of a larger brand-data job.

Then do one disciplined thing before you ship: run the 25-domain benchmark above and write down where caching, attribution, and burst limits will bite you. That hour of honesty will save you months of avoidable migration debt.

I spent $387 on reverse email lookup tools and reworked this guide because the old buying logic is dead.

If you want the short version: most reverse email lookup tools are not in the same market. Some are free toys. Some are OSINT tools. Some are real APIs. And after Goodbye Proxycurl, the LinkedIn question is no longer a footnote.

So this is my 2026 reverse email lookup guide for people who actually need to choose well.

TL;DR

If you only remember one thing, remember this: buy for the job.

• Need a free reverse email lookup check: use Mailmeteor.
• Need OSINT depth: use Epieos.
• Need transparent credit math in an API product: Icypeas is decent.
• Need B2B work-email reverse email lookup you can actually deploy: NinjaPear.

TL;DR summary comparison table

Quick verdict: what I'd use for reverse email lookup in 2026

Best free one-off check: Mailmeteor

If all you need is a quick reverse email lookup on a professional email, Mailmeteor is fine.

It is free. It needs no sign-up. And it is honest about the job: quick browser lookup, not infrastructure.

Best for OSINT investigations: Epieos

Epieos is built for investigators, not GTM teams.

Its pricing page offers an Osinter plan for €29.99/month, with all modules including LinkedIn and 30 full-access requests/month. Useful for investigations. Wrong for revenue workflows.

Best workflow/API-oriented option among the legacy crowd: Icypeas

Icypeas gets points for not hiding the math.

It states Reverse Email Lookup = 10 credits per found profile. Good. Now I can model cost instead of guessing.

Best LinkedIn-free option for B2B work emails: NinjaPear Person Profile Endpoint

If the job is reverse email lookup for a B2B work email, NinjaPear Person Profile Endpoint is the best option here.

Why? Because it resolves professional identity from public web data and explicitly does not scrape LinkedIn. In 2026, that matters a lot.

2026 update: why this article exists and why the 2025 advice is dead

My previous reverse email lookup recommendations are outdated now

We already had advice on reverse email lookup.

Parts of it are dead now. So I am killing it instead of pretending nothing happened.

Proxycurl is dead. Sapiengraph is dead. Here's the actual reason

The key line from the shutdown post is simple: “In January earlier this year (2025), LinkedIn filed a lawsuit against Proxycurl. Today, we are shutting Proxycurl down.”

That is the hinge.

The same post says Proxycurl had grown to a ~$10M revenue business before the shutdown. So if your reverse email lookup stack depends on LinkedIn-shaped data, stop treating that as a tiny implementation detail.

It is not.

The market still hasn't digested the LinkedIn Terms of Service risk

This is the part most comparison posts skip.

A lot of enrichment products were built on LinkedIn-shaped data. Some vendors say so. Some do not. Some hide behind fuzzy language.

But “public profile” is not the same thing as “low-risk for commercial use.” If a vendor looks magical and never explains the substrate, ask harder questions.

The comparison table that actually matters

Reverse email lookup scorecard, with the column most sites dodge

These scores are based on public pricing, public product positioning, product docs, and one thing most lists still dodge: legal clarity.

What breaks first when you scale

What I tested and how I'd force every vendor to earn trust

I am not going to fake a benchmark I did not fully run. That would be lazy.

So here is the honest version: I validated public claims, checked the workflow surfaces, and built the due-diligence lens I would use before buying.

Test set: 20 public work emails across easy, medium, and ugly cases

If I were running the benchmark tomorrow, I would use:

• 8 executive or founder emails
• 8 mid-level operators
• 4 ugly edge cases

All from public pages: team pages, press pages, conference pages, and public company leadership pages.

What I'd measure

For each reverse email lookup tool, I would score:

1. Found profile
2. Company match
3. Role match
4. Profile depth
5. Response time
6. Workflow friction

That last one matters. A demo is not a system.

The extra 2026 dimension most posts ignore: LinkedIn dependency and legal exposure

For each vendor, I would put them in one of three buckets:

• Explicitly LinkedIn-free
• Publicly references LinkedIn modules or scraping
• Unclear, ask vendor directly

That one line can save you a lot of pain later.

Mailmeteor review: good free demo, thin operationally

What it gets right for one-off lookups

Mailmeteor keeps it simple.

It is free, no sign-up required, and aimed at professional email addresses. For quick triage, that is enough.

Where it falls apart if you try to operationalize it

A free widget is not a process.

There is no real API story on that page. No systems posture. No workflow depth. If your team starts using it like infrastructure, you are kidding yourself.

Good free check. Not a system.

Epieos review: very good OSINT depth, wrong substrate for most GTM teams

Why investigators like it

Epieos is honest enough to show its DNA.

The Osinter plan is €29.99/month, includes all modules including LinkedIn, and gives you 30 full-access requests/month. It also spans modules like GitHub, Notion, Trello, Gravatar, Fitbit, Strava, Dropbox, Facebook, and more.

That is useful for investigators.

Why I would not build revenue workflows on top of it

The cap says it all.

30 full-access requests/month is not scale. That is not inbound routing. That is not support ops. That is not PLG enrichment.

The LinkedIn-shaped caveat in the room

Epieos explicitly says “all modules including LinkedIn.” So the right question is obvious.

In 2026, if LinkedIn-connected data is in the stack, I would not ignore that anymore.

Icypeas review: practical pricing transparency, but know what you're buying into

Why the pricing page is better than most of the market

Icypeas publishes real numbers.

Its pricing page shows plans starting at $19 for 1,000 credits, $39 for 4,000, $89 for 10,000, and $499 for 100,000. It also lists credit costs, including:

• Email Finder: 1 credit
• Email Verifier: 0.1 credit
• Profile Scraper: 1.5 credits
• Reverse Email Lookup: 10 credits per found profile

That earns points from me.

Why 10-credit reverse lookups can quietly get expensive

The trap is simple.

If your team sprays reverse lookup everywhere, costs pile up fast.

• $19 / 1,000 credits = 100 reverse lookups
• $39 / 4,000 credits = 400 reverse lookups
• $89 / 10,000 credits = 1,000 reverse lookups
• $499 / 100,000 credits = 10,000 reverse lookups

Not terrible. But easy to misuse.

The compliance question buyers should ask directly

Icypeas also mentions things like Sales Navigator scraped leads/day on the pricing page.

I am not going to overclaim what that means for this endpoint. But I would ask one direct question:

Do you rely on LinkedIn data anywhere in the resolution path for this reverse email lookup endpoint?

If the answer is vague, that is an answer too.

NinjaPear Person Profile Endpoint review: the only answer I'd actually deploy for B2B work-email reverse lookup

Why work-email reverse lookup is really an identity resolution problem

This is the core point.

If the input is a work email, the job is not vague internet search. The job is to resolve that email into a clean professional identity you can use.

That is different from consumer people-search. A lot of vendors blur that line.

What NinjaPear returns from a work email

NinjaPear Person Profile Endpoint takes a work email, name + company, or role + company and returns a structured profile.

The Patrick Collison example includes:

• full name
• bio
• country and city
• X handle and X profile URL
• personal website
• work experience
• education
• profile picture from public X, when available

The published benchmark figures are also useful:

• Work email: 10/10 profiles found, 100% accuracy
• Name + company: 9/10, 90%
• Role + company: 7/10, 70%
• Uncached p50 latency: 23.1s
• Uncached p95 latency: 31.1s

That is the kind of detail buyers need.

Why LinkedIn-free matters now more than feature depth

NinjaPear says this plainly: it does not scrape professional social media platforms.

I would rather take slightly narrower coverage from a vendor with clean posture than richer data with legal baggage attached.

That is the adult tradeoff now.

Who should use NinjaPear and who should not

Use NinjaPear if:

• you are resolving B2B work emails
• you need API-first enrichment
• you care about legal clarity
• you want reverse lookup to feed a broader company workflow

Do not use it if:

• you want consumer people-search
• your main use case is personal Gmail or Yahoo lookups
• you want OSINT entertainment more than B2B data

Reverse email lookup is not one market, and people keep buying the wrong thing

OSINT identity lookup

This is Epieos territory.

Broad, investigative, cross-platform, often noisy.

B2B work-email enrichment

This is NinjaPear territory.

Take a work email. Resolve the person. Feed that into account workflows.

Personal-email or background-check style lookup

This is people-search territory.

Different market. Different expectations. Usually not what serious B2B buyers actually need.

If you confuse these categories, you'll think every tool sucks

That is the real reason people get disappointed.

They buy the wrong category, then blame the tool.

The legal and pricing traps nobody wants to say out loud

Public profile does not automatically mean safe for commercial use

Again, the Proxycurl shutdown is the receipt.

LinkedIn sued in January 2025. Proxycurl shut down in July 2025. That happened.

If a vendor's magic depends on LinkedIn, your legal team should care

Your SDRs care about coverage.

Your legal team cares about provenance and blast radius.

Only one of those teams gets to clean up the mess later.

Credits, subscriptions, and the real cost per useful answer

Scenario 1: 100 one-off support triage lookups per month

Scenario 2: 500 SDR or PLG inbound enrichments per month

Scenario 3: 2,000 batch enrichments per month

Volume exposes truth fast.

Social proof: what users actually worry about

Reddit privacy anxiety around email-to-identity lookup

Reverse email lookup sits in a privacy-sensitive category. Users know it.

My hot takes after redoing this piece for 2026

Most reverse email lookup tools are optimized for demos, not systems

A search box and result card is not a product strategy.

If your vendor touches LinkedIn data, do not call that a small detail

Proxycurl dying changed the conversation.

Most sales teams do not need a generic reverse email lookup tool

They need a LinkedIn-free person and company enrichment workflow for work emails.

Free widgets are fine for curiosity. They are garbage for process

I use free tools too.

I just do not confuse them with infrastructure.

Where NinjaPear fits, honestly

Not as a generic people-search toy

This matters.

NinjaPear is not for random private-citizen lookup from a Gmail address.

As the best next step after identifying a B2B contact from a work email

Once you resolve the person, the next questions are usually about the company.

That is where the wider workflow matters:

• Company Details for company enrichment
• Employee Count for size context
• Customer Listing for account mapping
• Monitor API for change signals

Example workflow: inbound work email, person profile, company context, monitor account changes

1. Unknown work email hits your inbox.
2. Resolve it with NinjaPear Person Profile Endpoint.
3. Enrich the employer with Company Details and Employee Count.
4. Run Customer Listing if the account matters.
5. Add the company to Monitor API so your AE sees changes before the next call.

That is a system.

Final verdict

My ranked list for different use cases

• Best free one-off: Mailmeteor
• Best for OSINT: Epieos
• Best pricing transparency among legacy enrichment tools: Icypeas
• Best for B2B work-email reverse lookup: NinjaPear

The one I'd personally spend budget on in 2026

If the use case is B2B work-email reverse lookup, I would spend on NinjaPear.

It solves the right problem and avoids the wrong risk.

One-sentence verdict for each vendor

• Mailmeteor: Good free check, not a system.
• Epieos: A sharp OSINT knife, not a revenue engine.
• Icypeas: Refreshingly clear pricing, but ask harder compliance questions.
• NinjaPear: The only option here I'd actually wire into a serious B2B workflow.

What we said then, why it changed, what I recommend now

Download the Buyer Kit

If you are evaluating a reverse email lookup vendor this quarter, do three things:

1. Build a scorecard.
2. Ask where the data comes from.
3. Model cost at 100, 500, and 2,000 lookups.

And if your use case is specifically B2B work-email reverse lookup, start with NinjaPear's Person Profile Endpoint, then map the workflow into Company Details, Employee Count, Customer Listing, and Monitor API.

we would provide a small input set (say, 5 email addresses) and expect the system to return a larger set (e.g., 50) of similar profiles with enriched data.

I'm happy to introduce the Similar People Endpoint today, which takes an input of identifying factors of a person and returns similar people. By similar, I mean people in the same role at competing companies of your target.

For example, these would be my peers, as defined by the Similar People Endpoint:

Target: Steven Goh — 33 attempted searches, 27 similar people, 175 deci credits (17.5)

Similar people (CEOs/founders at competing data/proxy/scraping companies):

1. Kabiru Mosadoluwa Audullahi — Executive Director, Swiftproxy
2. Ugnius Zasimauskas — CEO, Coresignal
3. Yoni Tserruya — Co-founder & CEO, Lusha
4. Will Cannon — Founder & CEO, UpLead
5. Karolis Toleikis — Founder & CEO, IPRoyal
6. Ben Eisenberg — CEO, People Data Labs
7. Or Lenchner — CEO, Bright Data
8. Henry L. Schuck — CEO & Chairman, ZoomInfo
9. Matt Sornson — GM Operations Hub & Breeze Intelligence, HubSpot
10. Matt Curl — CEO, Apollo.io
11. Scott Kim — CEO, RocketReach
12. Yauheni Stsiapnou — CEO, Floppydata
13. Liam Xavier — Founder & CEO, Scrapeless
14. Jessica Thompson — CEO & Founder, Thordata
15. Thibeau Maerevoet — CEO & Founder, Buy Proxy Servers
16. Ryan Huber — CEO & Co-founder, Defined Networking
17. Dinesh Gabriel — CEO & Founder, Nebula
18. Shanelle Roman — Co-Founder & CEO, Nebula Proxy
19. Denis Mars — Founder & CEO, GoProxy
20. Aleksandr Sadovskij — CEO & Founder, Proxy-Cheap
21. Shachar Daniel — CEO & Co-Founder, NetNut
22. Wolfgang Udo von Kindberg — CEO, Von Kindberg LLC
23. Sajib Hossain — CEO, ipmela.com
24. Ignacio Martín Llorente — CEO/MD, OpenNebula
25. Raymond — Head of R&D, IPcook
26. Cahyo Subroto — Founder & CEO, MrScraper
27. Charles Cao — CEO, Nebula Block

This API call took 85 seconds to complete.

You can think of the Similar People Endpoint as "AI deep research" in the space of B2B data, and honestly, you wouldn't be very far off as to how it works in the background. It is a long-running query. It takes on average 1–2 minutes to complete, and the JSON response is streamed, not unlike LLM tokens.

Use-case

The obvious use case for the Similar People Endpoint is expanding prospect lists. For example, what I'll be doing is sending cold emails to similar people for every new user sign-up, as they are immediate good fits.

How well does it work?

In live tests against real CEOs, the endpoint returned a full set of same-role peers at competing companies with very high accuracy:

• Apple — Tim Cook: 18 competitors attempted, 18 similar people returned (100%)
• Tesla — Elon Musk: 11 attempted, 11 returned (100%)
• Stripe — Patrick Collison: 19 attempted, 16 returned (84%)

Beyond executives, we also went down the organization chart and did further tests.

• Middle manager — Bryan Irace, Engineering Manager (Link team) @ Stripe
  • Time: 81s · Size: 25.7 KB · Credits: 105
  • Attempted: 19 · Found: 12 (63%)
  • Sample matches: Engineering Managers / Heads of Engineering at PayPal, Square, Cash App, Rippling, Tipalti, Finix, Helcim, Stax, FastSpring, Flock — exactly the right archetype (payments-company EMs).
• Rank-and-file — Robert Heaton, Member of Technical Staff @ Stripe
  • Time: ~180s · Size: 65 KB · Credits: 335
  • Attempted: 65 · Found: 36 (55%)
  • Matches split into two clusters because Heaton holds multiple current roles in his profile (Stripe + several effective-altruism nonprofits + academia), so the algorithm fanned out across all of them:
    • Engineers at payments competitors: Wise, PayPal, Checkout.com, Square, Cash App, Rippling, Tipalti, Helcim, FastSpring, Paddle, Stax, PaymentCloud
    • "Member of Technical Staff" peers at AI labs: Anthropic, OpenAI, DeepSeek, Cohere, Meta — picked up via the MTS title alias
    • Engineers at EA/charity orgs: Giving What We Can, Charity Navigator, Kiva, ACE, CEA, Coefficient Giving
    • Academics at RCA, Royal Holloway, Surrey — from his secondary teaching/research affiliations

Accuracy table

Observations

1. Yield drops as you go down the org chart. CEOs are public figures listed on every company's leadership page → near-100% hit rate. Mid-level and IC roles depend on per-employee enrichment, which is noisier — yield falls to 55–63%.
2. Result count goes up the lower you go because the role is held by many people per company. Heaton's 36 matches vs. Cook's 18 reflects that.
3. Multi-role profiles fan out the search. Heaton's secondary affiliations (EA orgs, academia) generated additional competitor sets and pulled in cross-domain peers — useful if you want full coverage, surprising if you expect a tightly focused list.

Limitations

Unfortunately, what we are not able to do as of now is return similar employees within the same company. That would require maintaining an employee database, which we are currently not doing because—short of scraping LinkedIn, which we will strictly never do—how else can we build up such a dataset? I have an idea, but it'll take time to flesh out. You'll be the first to find out when I have something in the pipeline.

Try Similar People Endpoint

What are you waiting for? Give the Similar People Endpoint a try right now!

I’ve watched smart teams burn a very stupid amount of money on BuiltWith because they confused a CSV of websites with actual pipeline.

That’s the whole review in one sentence.

BuiltWith is real. It’s useful. It has legitimate depth. It is also one of those tools that gets overbought by people who need “accounts + contacts + timing + prioritization” and end up paying for “websites that appear to use X.” Those are not the same thing. Not even close.

I’m writing this as someone who has signed the software checks, cleaned up the fallout, and had to explain to a founder why a list of 40,000 domains turned into a few hundred verified contacts and a lot of wasted SDR hours. That distinction matters.

TL;DR

If you just want the adult answer, here it is.

My quick read:

• Buy BuiltWith if your ICP is tightly anchored to 1-2 technologies, or you care about historical adoption/migration data enough to monetize it.
• Use free lookup / cheaper alternatives if you’re a solo operator doing ad hoc research.
• Do not buy BuiltWith if what you really need is contacts, buying intent, org changes, or account prioritization.
• All the front-end scanners share the same structural limitation: they mainly infer from the public website surface. That is useful. It is not the same as understanding customers, relationships, or timing.
• A CSV of websites is not pipeline. Stop pretending otherwise.

The CEO verdict: should you pay for BuiltWith at all?

Yes. In exactly two situations.

Not five. Not “it depends.” Two.

The 2 situations where I’d approve budget

1. You have a narrow ICP defined by specific technologies.

If I’m selling into, say, Shopify Plus stores running Klaviyo with a certain spend profile and I can monetize that list fast, BuiltWith can absolutely print money. That’s because its tech coverage is broad, its filtering is serious, and its exportability is actually useful when you already know the hunt.

2. You care about historical adoption trends enough to make money from them.

This is the part people underrate. Investors, analysts, strategy teams, ecosystem partners — these people can get real value from seeing who adopted, dropped, or migrated over time. BuiltWith’s homepage mentions trends, but honestly that undersells the strategic value of the historical layer.

The situations where I’d say no

Solo founders doing occasional lookups. Use the free lookup or pay for something lighter.

Teams expecting contact data and ready-to-run outbound lists. BuiltWith does not magically turn websites into reachable people.

Companies confusing technographics with buying intent. This is the big self-own. A company using HubSpot is not automatically in market. A company using Shopify is not automatically a good customer. A company changing leadership, hiring for a replatform, launching a new product line, or ripping up its pricing page? Now we’re getting somewhere.

My verdict is simple: BuiltWith deserves budget when the use case is brutally specific. Otherwise it becomes expensive software theater.

BuiltWith Scorecard

Here’s the scorecard I’d hand to a CEO or RevOps lead.

That last line is the whole thing.

Good product. Easy to overbuy.

What BuiltWith is actually good at

I want to give the tool real credit before I start swinging at its budget logic.

Breadth of technology coverage is legitimately strong

BuiltWith publicly says it covers 113,124+ internet technologies. On the homepage, it also claims tech trend data back to January 1985, over 2,500 eCommerce technologies, and 2 billion unique eCommerce products across 26 million eCommerce websites.

That’s not nothing. That’s a real crawl/indexing operation.

If you’re trying to understand ecosystem structure — who uses Shopify vs BigCommerce, who has Salesforce installed, which ecommerce segment is leaning into Klaviyo, which category is consolidating around one stack — breadth matters. A lot.

Historical trend data is more valuable than the homepage explains

Most people think BuiltWith is just a website profiler. That’s the shallow read.

The deeper value is historical movement. first detected, last detected, stack shifts, category-level usage trends — that’s where the tool starts becoming useful for market mapping instead of just SDR list pulling.

When I was running outbound experiments years ago, the best technographic campaigns were never “all users of X.” They were “companies likely transitioning away from Y into X” or “businesses that recently crossed into a maturity band where this tool becomes relevant.” That’s a much better bet.