how to scrape linkedin data without getting banned (2026)

scraping linkedin without bans in 2026 comes down to four things: residential or mobile proxies (never datacenter), aged accounts with established activity, slow request rates (under 80 actions per day per account), and either a managed scraping api or playwright with anti-detection. linkedin actively detects automation. one ip + one fresh account + 200 requests in an hour = ban within 24 hours. this guide covers the legal context, the technical setup, and how to recover when accounts get restricted.

we cover legality first, then the proxy stack, account discipline, browser automation, managed api alternatives, and a 2026 ban-recovery playbook.

is linkedin scraping legal in 2026?

scraping public linkedin data is generally legal in the us under hiq v linkedin (2022) and follow-on rulings. the courts have repeatedly held that scraping public web data is not a violation of the computer fraud and abuse act.

scraping linkedin still violates linkedin’s terms of service. tos violations are not criminal but they give linkedin grounds to ban accounts and pursue civil action against commercial scrapers in some cases.

eu and uk law is stricter. gdpr requires a lawful basis (consent, contract, or legitimate interest) for processing personal data. scraped linkedin data falls under gdpr if it includes eu data subjects. document your lawful basis before processing, and respect data subject rights including erasure requests.

read linkedin’s user agreement for the current commercial-use restrictions. for a deeper read on the legal landscape around lead-gen scraping see our b2b lead generation proxies guide.

what gets you banned in 2026

linkedin’s anti-bot stack flags four signals.

ip pattern. datacenter ips trigger immediately. shared residential ips with known scraper traffic also flag fast. mobile carrier ips have the longest leash.

session pattern. login from a new ip with no warm-up history is suspicious. 50 profile views in 10 minutes is a classic bot signal. clicking through every profile from a search result without scrolling looks robotic.

browser fingerprint. headless chrome without anti-detection patches is detected within minutes. residential proxy + plain selenium = ban in under an hour.

account age and activity. brand new accounts with zero connections and a thin profile that suddenly perform 500 actions trip every alarm. aged accounts with real history get more leniency.

beat all four and bans become rare. miss any one and accounts cycle through faster than you can warm them.

the proxy stack

mobile proxies are the safest tier. linkedin sees thousands of users behind each carrier-grade nat ip, so individual scraping signals are diluted. expect to pay $50 to $150 per port per month.

residential proxies are the value pick. session-rotating residential pools work for most scraping at $4 to $7 per gb. choose providers with sticky sessions of 10+ minutes so a single profile-view session does not change ip mid-flow.

datacenter proxies are unusable for linkedin in 2026. even premium isp proxies (which are residential-issued datacenter ips) get blocked within a few requests.

assign one proxy per linkedin account. never share an ip across multiple accounts. linkedin’s session correlation flags shared ips fast.

account discipline

aged accounts are non-negotiable in 2026. linkedin treats accounts under 6 months old with no activity as bots by default. for production scraping you need accounts with at least 100 connections, a complete profile, posted content from real timestamps, and a normal usage history.

three options for account supply.

option 1: warm your own. spend 30 to 60 days on each account: login, scroll, accept connections, post once a week, like a few posts daily. boring but the accounts last.

option 2: buy aged accounts. resellers sell 1-year-old accounts with 500+ connections for $50 to $200. quality varies wildly. budget for replacement.

option 3: managed scraping apis. let bright data, apify, or proxycurl handle the account problem entirely. you pay per query, they handle bans on their side. cleanest for production.

never run more than 80 to 120 actions per account per day. one action = one profile view, one search, or one connection request. above that, ban risk spikes hard.

browser automation: playwright with anti-detection

for self-managed scraping, playwright with anti-detection patches is the baseline.

from playwright.sync_api import sync_playwright
import time
import random

PROXY = {
    "server": "http://proxy.example.com:8080",
    "username": "user-session-abc123",
    "password": "pass",
}

def scrape_profile(profile_url, session_cookie):
    with sync_playwright() as p:
        browser = p.chromium.launch(
            headless=True,
            proxy=PROXY,
            args=[
                "--disable-blink-features=AutomationControlled",
                "--no-sandbox",
            ],
        )
        context = browser.new_context(
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                       "AppleWebKit/537.36 (KHTML, like Gecko) "
                       "Chrome/127.0.0.0 Safari/537.36",
            viewport={"width": 1920, "height": 1080},
            locale="en-US",
            timezone_id="America/New_York",
        )
        context.add_cookies([{
            "name": "li_at",
            "value": session_cookie,
            "domain": ".linkedin.com",
            "path": "/",
        }])

        page = context.new_page()
        page.goto(profile_url, wait_until="networkidle")
        time.sleep(random.uniform(2, 5))

        page.mouse.wheel(0, 600)
        time.sleep(random.uniform(1, 3))
        page.mouse.wheel(0, 800)
        time.sleep(random.uniform(2, 4))

        name = page.locator("h1").inner_text()
        headline = page.locator(".text-body-medium.break-words").first.inner_text()

        browser.close()
        return {"name": name, "headline": headline, "url": profile_url}

the --disable-blink-features=AutomationControlled flag removes the most obvious headless tell. sleeps and mouse-wheel events simulate human pacing. timezone, locale, and user-agent match a typical us desktop user.

for stronger anti-detection, use playwright-stealth or a real antidetect browser like adspower or gologin. plain playwright is detectable by sophisticated fingerprinting.

for the broader python scraping context see our web scraping with python guide.

sticky sessions across the scrape session

linkedin tracks ip across a session. switching ip mid-session looks like account hijacking and triggers a security challenge.

def session_username(account_id):
    """build a sticky username for residential providers that support it."""
    return f"user-session-{account_id}"

def proxy_for_account(account_id):
    return {
        "server": "http://proxy.example.com:8080",
        "username": session_username(account_id),
        "password": "pass",
    }

most residential providers (smartproxy, oxylabs, soax) support session usernames that pin a single residential ip for 10 to 30 minutes. use the same session id for the duration of the linkedin scrape, then rotate when the session expires naturally.

rate limits in practice

based on 6 months of data across 30 aged accounts running through residential proxies in 2026, here is what stayed unbanned:

• profile views: under 80 per day per account
• searches: under 25 per day per account
• connection requests: under 15 per day per account (lifetime cap of 100 per week)
• messages to connections: under 50 per day per account
• session length: 30 to 90 minutes per session, 1 to 2 sessions per day
• gap between sessions: at least 4 hours

push past these and ban rates spike. stay below them and accounts last 6 to 12 months on average before any restriction.

managed scraping apis: the easier path

self-managed linkedin scraping is a job. you maintain account warming, proxy rotation, anti-detection patches, and ban recovery. for many teams the time cost beats the api cost.

managed options in 2026:

bright data linkedin dataset. pre-scraped public profiles. updated continuously. you query by url or company. roughly $0.001 to $0.01 per record depending on volume. no scraping risk on your side.

apify linkedin scraper actors. pay per actor run. simpler than building your own; still subject to linkedin’s anti-bot. 2026 prices: roughly $1 to $3 per 1,000 results.

proxycurl. linkedin profile, company, and job api. enterprise-friendly with response-time slas. $0.10 to $0.30 per profile lookup at typical volumes.

phantombuster. no-code linkedin automation. covers scraping plus connection requests and messaging. see our breakdown in outscraper vs phantombuster vs hunter.io.

for production teams, the managed apis are the right choice unless you need volume that exceeds their rate limits or you are scraping data they do not offer.

what to do when an account gets restricted

linkedin restricts accounts in stages: warning, partial restriction (no search, no messages), full restriction (login redirects to verification), then permanent ban.

at warning stage: stop all automation for 7 to 14 days. log in manually from a regular browser on the same proxy. do normal user activities (scroll, like 1 to 2 posts, accept 1 connection). most accounts recover.

at partial restriction: same playbook plus complete identity verification if linkedin asks (selfie, government id). if you skip verification, the account moves to full restriction. for accounts you bought, this is usually game over.

at full restriction: usually unrecoverable without verification. for managed-api stacks, this is on the api provider, not you.

at permanent ban: replace the account. log the proxy + account combo so you do not reuse the proxy for the next account.

ethical and security notes

if you scrape eu data subjects, you must respect erasure requests. publish a privacy policy that lists linkedin as a data source and provides a removal email. process removals within 30 days.

never scrape data behind a login that requires special permission (closed groups, private messages, premium-only fields). that crosses into the cfaa unauthorized-access territory in the us and is a clear gdpr violation in the eu.

cold email or cold dm using scraped data still requires lawful basis in the eu and uk and a clear opt-out everywhere. a working email is a tool, not a license.

faq

can i scrape public linkedin profiles legally?

in the us, public profile data scraping is generally legal under hiq v linkedin, but it violates linkedin’s tos. in the eu and uk, gdpr requires a lawful basis even for public data when it identifies a person. always document your basis and offer opt-out.

what proxies should i use for linkedin scraping?

mobile proxies are safest. residential proxies with sticky sessions of 10+ minutes are the value pick. datacenter and isp proxies are blocked instantly in 2026. budget $5 to $7 per gb for residential or $50+ per port per month for mobile.

how many requests per day before linkedin bans?

aged accounts on residential proxies tolerate roughly 80 profile views, 25 searches, and 15 connection requests per day. fresh accounts on datacenter ips tolerate maybe 20 to 50 requests before banning.

is selenium or playwright better for linkedin scraping?

playwright is the better default in 2026. its anti-detection options are richer, the api is cleaner, and it handles modern js rendering more reliably. selenium still works but requires more patches to avoid headless detection.

do i need a paid linkedin sales nav account to scrape effectively?

not strictly. public profile scraping works without a paid account. sales nav unlocks deeper search filters and lead lists, which is useful for outbound. paid accounts also tolerate slightly higher rate limits before triggering anti-bot.

should i use a managed linkedin api or build my own scraper?

for under 5,000 profiles per month, managed apis (bright data, apify, proxycurl) are usually cheaper than the engineering plus account management cost. for higher volume or unique fields not in the public datasets, build your own. budget for warming aged accounts, residential proxies, and ongoing maintenance.

the bottom line

linkedin scraping in 2026 is harder than 2022 because linkedin’s anti-bot stack got better. but it is also more accessible because managed datasets cover most common use cases at a per-record price that beats diy.

self-managed approach: aged accounts, residential or mobile proxies (one per account), playwright with anti-detection, conservative rate limits. expect to replace 10 to 20 percent of accounts every quarter.

managed approach: pay $0.001 to $0.30 per record depending on freshness and depth. zero ban exposure. faster time-to-data.

for most teams in 2026 the managed approach wins on total cost. for teams scraping at very high volume or extracting fields managed apis do not surface, the diy stack still has a place. either way, document your gdpr basis and respect opt-outs. it is the difference between a sustainable lead-gen channel and a pile of legal exposure.

How to Scrape Realtor.com Property Data in 2026 (Bypass Next.js Protection)

the cleanest way to scrape realtor.com in 2026 is to extract the embedded __NEXT_DATA__ json from each listing page. it contains everything the website renders, in structured form, with no parsing brittleness. you’ll need a residential proxy to avoid the akamai bot manager block, and python with httpx + parsel does the rest. this tutorial ships working code.

why next_data is the trick

realtor.com runs on next.js. every server-rendered page bakes a hidden <script id="__NEXT_DATA__" type="application/json"> block into the html. inside that block sits the entire react state for the page: full property details, agent info, school info, pricing history, photos, the whole structured tree.

if you parse the html directly (price from .price-display, address from .address-line), realtor.com will rename or restructure that markup every few months. your scraper breaks. if you parse __NEXT_DATA__, you get raw json from their backend, and they rarely change those keys because their own frontend depends on them.

we cover this pattern in depth in our javascript-rendered pages scraping guide, but realtor.com is the textbook case.

the anti-bot situation

realtor.com sits behind akamai bot manager and a custom rate limiter. behavior:

(1) datacenter ips: blocked at the cdn edge. you get a 403 with a captcha challenge page.

(2) residential or mobile ips with a clean fingerprint: 200 ok response, 50-200 requests per ip per hour before throttling.

(3) high-volume requests from the same ip: 429 rate limit, 5-15 minute cooldown.

practical implication: you need rotating residential ips with sticky sessions long enough to fetch a single page. you don’t need a full headless browser, plain http requests with the right headers work fine.

installing dependencies

pip install httpx parsel orjson

httpx for async http, parsel for css selectors, orjson for fast json parsing. that’s it.

the basic listing fetcher

import httpx
import parsel
import orjson

HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/126.0.0.0 Safari/537.36"
    ),
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Cache-Control": "no-cache",
    "Pragma": "no-cache",
    "Sec-Ch-Ua": '"Chromium";v="126", "Not(A:Brand";v="24", "Google Chrome";v="126"',
    "Sec-Ch-Ua-Mobile": "?0",
    "Sec-Ch-Ua-Platform": '"macOS"',
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
    "Upgrade-Insecure-Requests": "1",
}

def fetch_listing(url: str, proxy: str) -> dict:
    with httpx.Client(
        proxies=proxy,
        headers=HEADERS,
        timeout=30,
        http2=True,
    ) as client:
        resp = client.get(url)
        resp.raise_for_status()

        sel = parsel.Selector(resp.text)
        data = sel.css("script#__NEXT_DATA__::text").get()
        if not data:
            raise ValueError("__NEXT_DATA__ missing - likely blocked")

        return orjson.loads(data)

if __name__ == "__main__":
    proxy = "http://user-session-abc:pwd@gate.provider.com:8000"
    data = fetch_listing(
        "https://www.realtor.com/realestateandhomes-detail/123-Main-St_Anytown_CA_90210_M12345-67890",
        proxy,
    )
    print(orjson.dumps(data, option=orjson.OPT_INDENT_2).decode())

key headers:

Sec-Ch-Ua block must match the user-agent. mismatched user-agent and sec-ch-ua is one of the fastest ways to get flagged.

http2 enabled. realtor.com uses http2 internally and bot managers flag plain http/1.1 client behavior on http2 sites.

navigating next_data

the json structure looks like this (pruned):

{
  "props": {
    "pageProps": {
      "initialReduxState": {
        "propertyDetails": {
          "property": {
            "list_price": 750000,
            "address": {
              "line": "123 Main St",
              "city": "Anytown",
              "state": "CA",
              "postal_code": "90210"
            },
            "description": {
              "beds": 3,
              "baths": 2.5,
              "sqft": 1800,
              "year_built": 1985,
              "type": "single_family"
            },
            "photos": [...],
            "advertisers": [...],
            "schools": {...},
            "tax_history": [...]
          }
        }
      }
    }
  }
}

the exact path varies slightly between listing types (single family, condo, lot, rental). a robust extractor walks the tree:

def extract_property(data: dict) -> dict:
    page_props = data["props"]["pageProps"]
    redux = page_props.get("initialReduxState", {})
    prop = redux.get("propertyDetails", {}).get("property", {})

    if not prop:
        # fallback for newer page structures
        prop = page_props.get("property", {})

    return {
        "price": prop.get("list_price"),
        "address": prop.get("address", {}).get("line"),
        "city": prop.get("address", {}).get("city"),
        "state": prop.get("address", {}).get("state"),
        "postal_code": prop.get("address", {}).get("postal_code"),
        "beds": prop.get("description", {}).get("beds"),
        "baths": prop.get("description", {}).get("baths"),
        "sqft": prop.get("description", {}).get("sqft"),
        "year_built": prop.get("description", {}).get("year_built"),
        "property_type": prop.get("description", {}).get("type"),
        "photos": [p.get("href") for p in prop.get("photos", [])],
        "agent_name": (prop.get("advertisers", [{}])[0]).get("name"),
        "schools": prop.get("schools"),
        "tax_history": prop.get("tax_history"),
    }

now you have clean structured data ready for a database.

scraping search results

the listing detail page is the easy part. search result pages also embed __NEXT_DATA__ with a list of properties:

def fetch_search_results(city: str, state: str, page: int, proxy: str) -> list:
    url = f"https://www.realtor.com/realestateandhomes-search/{city}_{state}/pg-{page}"
    with httpx.Client(proxies=proxy, headers=HEADERS, timeout=30, http2=True) as client:
        resp = client.get(url)
        resp.raise_for_status()
        sel = parsel.Selector(resp.text)
        data = orjson.loads(sel.css("script#__NEXT_DATA__::text").get())

    listings = data["props"]["pageProps"]["properties"]
    return [
        {
            "property_id": l.get("property_id"),
            "url": f"https://www.realtor.com{l.get('rdc_web_url', '')}",
            "list_price": l.get("list_price"),
            "address": l.get("address"),
        }
        for l in listings
    ]

a typical search returns 42 listings per page. multi-page pagination is just incrementing pg-N until the result list is empty.

the proxy setup

residential rotating with 1-5 minute sticky sessions is what you want. one ip per page fetch keeps the request footprint tiny. avoid mobile (overkill, more expensive) and datacenter (blocked).

import uuid

def make_session_proxy() -> str:
    sid = uuid.uuid4().hex[:12]
    return f"http://user-country-us-session-{sid}:pwd@gate.provider.com:8000"

generate a fresh session per page. if a request fails, generate another and retry.

handling 403 challenges

when akamai flags you, the response is a redirect to a challenge page or an html with "unable to verify" in the body. detect both:

def looks_blocked(resp: httpx.Response) -> bool:
    if resp.status_code == 403:
        return True
    body = resp.text.lower()
    if "unable to verify" in body or "challenge" in body:
        return True
    if "<script id=\"__next_data__\"" not in body:
        return True
    return False

retry with a fresh session. if you get blocked 3 times in a row from different sessions, the entire ip range is hot. wait 10-15 minutes before retrying.

throttling for politeness

even with rotating ips, hammering realtor.com is rude and gets your provider’s pool flagged. cap your request rate:

import asyncio
import random

async def throttled_fetch(url, proxy):
    await asyncio.sleep(random.uniform(2.0, 5.0))
    return await async_fetch_listing(url, proxy)

2-5 second delay per worker, 10-20 workers in parallel. you’ll fetch 200-400 pages/minute, which is plenty without abusing the site.

storing the data

a postgres table for structured fields, jsonb column for the full extracted payload (so you can backfill new fields later):

CREATE TABLE realtor_listings (
    property_id TEXT PRIMARY KEY,
    scraped_at TIMESTAMP NOT NULL DEFAULT NOW(),
    list_price NUMERIC(12, 2),
    address TEXT,
    city TEXT,
    state TEXT,
    postal_code TEXT,
    beds NUMERIC(4, 1),
    baths NUMERIC(4, 1),
    sqft INTEGER,
    year_built INTEGER,
    property_type TEXT,
    raw JSONB,
    UNIQUE(property_id, scraped_at)
);

if your data lands in bigquery instead of postgres, the same pattern works (we wrote a scraping to bigquery pipeline that fits this scraper directly).

scaling considerations

at 200 listings/min, scraping all active us listings (~1.5M) takes ~5 days. realistic budgets:

• proxy bandwidth: ~150kb per detail page = 250mb for 1500 listings. at $4/gb residential = $1/1500 listings.
• compute: a single python worker handles 200/min. for parallel scraping, deploy 5-10 workers across regions.
• storage: a million listings is ~3gb in postgres with the jsonb column.

cheap relative to the data value. real estate scraping pipelines that produce $5k-50k/month in saas revenue spend $200-800/month on infrastructure.

legal and ethical notes

scraping public listings is widely accepted. the data is published for the world to see. but: realtor.com’s tos forbids automated access. they can block your ip range, send a cease-and-desist, or pursue legal action if you redistribute their data commercially.

(1) don’t republish realtor.com’s photos or copy. fair use for analysis is one thing, building a competing listings site is another.

(2) don’t scrape pii (broker phone numbers, emails) and resell it.

(3) respect throttling. if they ratelimit, back off.

your use case (price analysis, market trends, lead generation for buyers) is usually fine. competing directly with mls licensees is a fast way to get sued.

frequently asked questions

why doesn’t realtor.com just block next_data entirely?

their own website depends on it. removing the embedded json would break their progressive enhancement and seo. they could obfuscate keys, but they haven’t, because the cost of breaking their own analytics tooling outweighs the gain of slowing scrapers.

can i scrape with playwright instead of httpx?

you can, but it’s overkill. realtor.com’s next_data is in the initial server response, so you don’t need to wait for js execution. httpx is 10x faster and 50x cheaper.

what residential proxy provider works best for realtor.com?

any reputable residential pool with us ips. our proxy provider comparison ranks them. avoid datacenter and avoid the smaller regional providers, your success rate suffers.

how do i scrape realtor.com photos?

photo urls are in the next_data payload. download them through the same proxy pool, but at higher bandwidth cost. budget ~3mb per photo, ~30mb per listing.

does realtor.com offer an official api?

not for public scraping. they license data through partnerships and via the underlying mls feeds. licensing fees are typically $thousands/month plus per-record charges. scraping is the budget alternative.

will my scraper survive realtor.com html changes?

the next_data approach is far more stable than css selectors. expect occasional key renames (every 12-18 months) but minor adjustments rather than full rewrites.

final thoughts

realtor.com is one of the cleaner real estate scraping targets in 2026 if you go through the front door (__NEXT_DATA__ extraction with residential proxies). most failures we see are from people trying to use datacenter ips, parse the rendered html, or run headless browsers when they don’t need to. the lighter your stack, the faster and cheaper your scraper. ship the simple httpx version first, add complexity only when something specific breaks.