Scrapling on OpenClaw: Running LinkedIn Agents at Scale

Why Scrapling’s LinkedIn agents can’t live without proxies

If you do any kind of B2B growth work, you already know this: LinkedIn is a gold mine and a minefield at the same time.

Inside Scrapling, we run OpenClaw‑powered agents that:

• search for very specific job titles and industries
• open hundreds or thousands of profiles
• extract structured data (title, company, location, seniority, stack hints…)
• push everything into a CRM or data warehouse

When we first experimented with “just a single server IP and a browser automation script”, things looked fine for a day or two. Then reality hit:

• CAPTCHAs started to pop up every few pages
• “Unusual activity detected” banners appeared more and more often
• search results were temporarily limited
• some test accounts were logged out and briefly restricted

Looking back, it’s not hard to see why this happens:

all traffic is coming from one noisy data‑center IP that looks exactly like a bot farm.

The usual way to de‑risk this is to put a residential proxy layer between your agents and LinkedIn.

A typical Scrapling + OpenClaw LinkedIn pipeline

Let’s walk through a simplified version of what Scrapling runs in production.

For a given campaign (say “Heads of Data in EU‑based Series B SaaS companies”), an OpenClaw workflow in Scrapling will:

1. read a list of target queries (e.g. “Head of Data”, “VP of Data Science”, “Director of Analytics”)
2. open LinkedIn search with filters for location, industry and seniority
3. scroll through the results and open profiles one by one
4. extract fields like:

• name and headline
• current company and role
• location
• skills / industry hints
• past companies from the experience section

1. send the structured payload into our internal “Scrapling” service and from there into the client’s CRM

If we try to run this whole flow from a naked data‑center IP, it starts tripping alarms in 1–2 hours.

To keep agents alive over weeks and months, two things are non‑negotiable:

• use residential proxies so traffic looks like it comes from real users
• shape traffic to look like normal browsing, not a benchmark script

How Bytesflows residential proxies fit into the picture

The way we think about it internally is simple:

Scrapling orchestrates OpenClaw agents; Bytesflows sits underneath as the rotating residential proxy layer.

Concretely, Bytesflows gives Scrapling:

• real residential IPs: addresses belong to ISP ranges, not data centers, which dramatically changes how automated traffic is scored
• automatic IP rotation: we can rotate per request or per session, so no single IP opens hundreds of profiles in a tight time window
• geo targeting: we can pin agents to specific countries or cities, which often changes both the search results and the risk profile
• reliable bandwidth: LinkedIn pages are heavy; slow or flaky proxies kill throughput very fast

From OpenClaw’s perspective inside Scrapling, we just point all LinkedIn‑related browsers at a single proxy endpoint and let Bytesflows handle the harder networking problems.

Wiring Bytesflows into OpenClaw (Playwright example)

Most Scrapling pipelines use Playwright under the hood.

Here’s roughly what the browser factory looks like in our LinkedIn agents:

import { chromium } from "playwright";

async function newLinkedInBrowser() {
  const browser = await chromium.launch({
    headless: true,
    proxy: {
      server: "http://p1.bytesflows.com:8001",
      username: process.env.BYTESFLOWS_USERNAME,
      password: process.env.BYTESFLOWS_PASSWORD,
    },
  });

  const context = await browser.newContext({
    viewport: { width: 1440, height: 900 },
    userAgent:
      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
  });

  return { browser, context };
}

Inside Scrapling’s OpenClaw agents we simply make sure that every LinkedIn task uses this factory.

The agent logic (scroll, click, extract) doesn’t need to know anything about proxies; Bytesflows is only configured here at the edge.

Use case #1: high‑value B2B lead lists

To make this less abstract, here’s the type of audiences Scrapling campaigns usually care about:

Under the hood, this is just “plain” OpenClaw plus a careful browser setup. The Bytesflows residential proxy layer is there to make the traffic pattern look more like normal user browsing and less like a synthetic load test.

• “Head of Engineering”, “CTO”, “VP of Product” in North America and Western Europe
• engineering leaders working with specific stacks (Kubernetes, Snowflake, Databricks…)
• decision‑makers in Series B or later‑stage SaaS companies

With Scrapling, OpenClaw and Bytesflows wired together, a typical campaign looks like this:

1. an agent reads a config file with titles, geos and industries
2. all browser sessions go out through Bytesflows residential proxies
3. we paginate slowly through search results with jittered scrolling and pauses
4. every one or two profiles, we wait for a few seconds and move the mouse around
5. extracted leads get pushed into Scrapling and from there into the CRM, along with the proxy/IP and timestamps we used

The “why proxies?” part is simple:

• a single data‑center IP opening 500 high‑value profiles per hour will not last long
• some searches are clearly geo‑sensitive; residential IPs in the right region give you both more relevant results and fewer flags

Use case #2: company org‑chart and team health

Another common pattern is “company health checks” for investors and corp‑dev teams:

• tracking headcount growth over time
• understanding the split between engineering, sales, operations, support…
• mapping the leadership team’s background

Here an OpenClaw agent will:

1. enumerate employees for a given company
2. bucket roles into rough functions and seniority levels
3. export that into charts or reports over time

Bytesflows residential proxies help us:

• spread those profile and search page visits over many IPs instead of hammering from one
• flip between regions to understand how globally distributed a team actually is

Use case #3: watching job changes on key accounts

For B2B sales and customer success, job changes can be incredibly valuable signals:

• your internal champion gets promoted → bigger budget, easier upsell
• the main decision‑maker leaves → time to rebuild the relationship
• a key engineer moves to a new company → potential warm intro

We use OpenClaw (through Scrapling) to run “change watcher” agents that:

1. periodically visit a set of important profiles
2. diff the current company/title against the last snapshot
3. trigger Slack or email notifications when something meaningful changes

To keep this running for months without drama, we again lean on Bytesflows:

• residential IPs keep the monitoring traffic under the radar
• rotation reduces the risk that one account/IP pair gets over‑profiled

A few hard‑earned tuning lessons

If you want your LinkedIn scraping to feel less like a weekend script and more like a product, a couple of things really matter:

• keep concurrency boring: slower and consistent beats spiky and aggressive every single time
• add noise to behavior: scroll, wait, occasionally click something that isn’t strictly required
• separate rotation strategies:
• for authenticated sessions, keep an IP stable within a session