How Reply.io Pulls 240,000+ Sales Navigator Leads Past the 2,500 Cap

Reply.io sells sales automation for a living. Their AI SDR writes the outreach, their database holds over a billion contacts — and when their team needs fresh leads from LinkedIn Sales Navigator, they hit the same wall as everyone else.

2,500 results per search. Aggressive rate limits. No export button.

Here's how they built around it — 240,595 leads later.

A sales platform that buys its collection layer

Which raises a fair question: a platform that already owns a billion-contact database — why would it scrape anything?

Because a static database and a live Sales Navigator search answer different questions. The database gives you reach. A fresh search gives you who matches this exact segment, today — current title, current company, current headcount.

For that, their ops team runs a dedicated lobstr.io workspace — three team members share it, customers since January 2026.

We already run our own enrichment and sequencing. What we needed was a collection layer for Sales Navigator that keeps up with our volume.

Anatol Kisil,VP of Product, Reply.io

Sales Navigator's 2,500-result wall

Three limits stack up:

1. Every search displays at most 2,500 results (100 pages of 25), whatever the real match count;
2. There is no export button — LinkedIn wants you reading profiles, not building files;
3. Pull too fast and LinkedIn answers with "too many requests" — then your account cools down for hours. The full list of thresholds is in our LinkedIn limits guide.

Reply.io's segments are exactly the painful kind. Their searches routinely match 3,000 to 9,000+ leads — the team once loaded a single task covering about 9,000 of them.

Do the math on that 9,000-lead segment. Past the display cap, 6,500 matches — 72% of the segment — are simply unreachable. You cannot even scroll to them.

Copy-pasting the visible rest is not a job anyone wants. And scraping it naively creates a subtler cost: recurring searches keep re-collecting the same leads, so you pay every month for profiles you already own.

So the problem is really three problems: the cap, the blocks, the duplicates. Their configuration solves all three.

Split, dedup, rotate

Two toggles in the advanced settings do the heavy lifting.

Skip Collected Leads (1) beats the duplicates. The scraper remembers every lead already in their collection, and stops paging a search when it is only re-finding them.

Split Search (2) beats the 2,500 cap. Instead of paging one big search into the wall, the scraper slices it into narrower sub-searches — tighter headcount bands, smaller geographies — each landing under the cap. Then it merges the results back into one list.

With Skip Collected Leads, we stopped paying twice for the same lead — the scraper already knows what we have.

Anatol Kisil,VP of Product, Reply.io

When the team wants tighter control, they add a third dial: a cap on unique results per run. During one August batch they set it to 500 leads per run — small enough to check quality between launches, instead of discovering a problem 9,000 rows deep.

This is their squid #7 processing a real search, on September 21:

Read the log top to bottom and you see the first two problems dying in order. "Splitting search into 10 sub-searches to reach beyond the 2,500 cap." Then: "3211 results found" — a count no manual export can even display.

And at the end: "This search is almost entirely already collected; stopping early instead of re-fetching duplicate pages." That's the third problem — duplicates — dying too.

The blocks? Two synced Sales Navigator accounts spread the load. When LinkedIn does throw a cooldown, the run pauses itself, uploads what it has, and relaunches at the scheduled retry — no babysitting.

One more detail, easy to miss in the run parameters: every enrichment function is switched off. No email finding, no profile deep-dive.

Reply.io has its own enrichment stack — what they need from us is the collection layer, raw and fast. The scraper does one job and stays out of the way.

The deliverable: deduplicated leads, one API call away

What lands on Reply.io's side is deliberately boring: structured rows.

One row per lead — name, position, company, LinkedIn profile URL. Already deduplicated against everything the workspace collected before, ready for their own enrichment and sequences.

curl -H "Authorization: Token $LOBSTR_API_KEY" \
  "https://api.lobstr.io/v1/results?squid=SQUID_HASH&page=1"

{
  "total_results": 3196,
  "page": 1,
  "data": [{
    "full_name": "Edouard Tabet",
    "position": "Co-founder",
    "company_name": "Eliot (Acquired by Airbnb)",
    "location": "Mountain View, California, United States",
    "degree": "3rd",
    "connections": 1198,
    "email": null,
    ...
  }]
}
f

We launch the searches and download the files. The caps, the blocks, the retries — that's not our problem anymore.

Anatol Kisil,VP of Product, Reply.io

240,595 leads in four months

I pulled the numbers from our production ledger — every run, every result, timestamped.

Between May 14 and September 21, 2026, Reply.io's workspace completed 65 runs and collected 240,595 Sales Navigator leads — roughly three runs a week, every week. Their biggest single run: 19,818 leads, in one go, from one search URL.

The curve flattens on purpose. By September, most of what their recurring searches return is already in their collection — so Skip Collected Leads stops the runs early, and they stop paying for leads they already own.

Scale that hardened the product

Case studies usually hide the support tickets. This one is better with them.

In late August, Reply.io's volume surfaced a real edge case: searches that mostly returned already-collected leads kept paging anyway — burning requests and triggering LinkedIn cooldowns. Their team reported it on August 26.

We identified the cause within two days and shipped the fix the week after: runs now stop early the moment a search is only re-finding known leads. A second hardening followed on September 8 — safer multi-thread behavior, and no re-visiting of already-visited leads within the same run.

That "stopping early" line in the run log above? That is the fix, live, doing its job three weeks later.

This is what a data vendor is actually for: customers like Reply.io push the scraper to volumes that expose the edges, and every fix ships to everyone. Their 240,595 leads made the product tougher for the next team's 240,595.