Is the Bright Data n8n node official?

Yes in authorship, with a caveat in distribution. Bright Data publishes it under its own npm scope, but it ships as a community node rather than a built-in n8n node, so n8n Cloud's community node restrictions apply and it has no page in n8n's documentation. There is also a similarly named third-party package from a different publisher, so check the scope before installing.

Why does my Bright Data workflow return no data?

Usually because the job is asynchronous and the workflow treated it as synchronous. A collection request returns a snapshot ID, not records. You have to poll a progress endpoint until the state is ready, handling collecting and digesting on the way and failed as terminal. A workflow that reads the trigger response as data will look successful and produce nothing.

Does Bright Data really only charge for successful results?

Mostly, with one documented exception worth planning around: unsuccessful attempts caused by incorrect user input are still billed. So a batch containing malformed or dead URLs costs money and returns nothing for those rows. Validating input before submission is a cost control measure, not just hygiene.

Is Bright Data's data collection compliant?

Bright Data collects public data only, and documents it. Their Acceptable Use Policy explicitly prohibits collection of non-public information, meaning anything behind a login, and bans impersonation, fake account creation, and any use violating applicable law or third party rights. They proactively block categories of web content including adult and governmental sites. On the security side they hold ISO 27001:2022, ISO 27017 and ISO 27018 certifications, publish a SOC 3 report, make SOC 2 available on request, and maintain a CSA STAR listing.

How do you use Bright Data with n8n?

Q: What does Bright Data's LinkedIn data actually contain?

Profile data rather than contact data. The Profiles schema covers name, location, current position, about, experience, education, certifications, languages, followers, connections and similar profiles. There is no email field. Each request triggers a live scrape with no cached or stale data, so it complements an email provider rather than replacing one.

Through a node Bright Data publishes itself, installed as a community node. The important thing to understand before building anything is that collection jobs are asynchronous: you trigger a job, receive a snapshot ID, and poll for completion. There is no push-only path, and designing an n8n workflow as though there were is the most common mistake.

What already exists

Is there a native Bright Data to n8n integration?

Bright Data authors and publishes the n8n node under its own npm scope, but distributes it as a community node rather than shipping it in n8n core. It is not in n8n's built-in node list and has no page in n8n's documentation. The node covers the Marketplace Dataset API, Web Unlocker, and the Web Scraper API. Bright Data also ships an MCP server with a free tier covering search and scrape tools, and a Pro tier adding structured social tools including LinkedIn profiles, companies, jobs, posts and people search.

It is a community node, so n8n Cloud's community node restrictions apply. Note there is also a similarly named third-party package by a different publisher. The official one is scoped to the Bright Data organisation.
Collection is asynchronous. You trigger a job, get a snapshot ID, then poll a progress endpoint through the states collecting, digesting, ready and failed. There is no push-only alternative, so the polling loop is your responsibility.
Batch requests are capped at 20 URLs per batch, with input capped at 1GB per batch. Concurrency is 100 batch requests or 1,500 single-input requests.
Downloads are capped at 5GB via the API and 1GB via webhook.
Jobs take anywhere from 30 seconds to several minutes, which shapes what you can reasonably do inside a single workflow execution.

The detail

What actually moves between Bright Data and n8n?

Web Scraper API: over 1,000 pre-built scrapers returning structured JSON per domain, scraped live on demand

Web Unlocker: a single API call returning clean HTML or JSON, handling proxy rotation, fingerprints, CAPTCHA and retries

Browser API: a remote browser driven through Puppeteer, Playwright or Selenium for pages needing full render and interaction

Marketplace Datasets: pre-collected data across 250+ domains, purchased in bulk rather than scraped on demand

LinkedIn scrapers: Profiles, Companies, Jobs and Posts, each with collect-by-URL and discover modes

Workplace data: Indeed at 53.9M+ records including work happiness and company ratings, Glassdoor at 35.5M+ records across company and review level

Proxy networks (residential, datacenter, ISP, mobile) when you are running your own scraper and only need IPs

In practice

Where Bright Data to n8n syncs go wrong

Treating an async job like a synchronous request

The single most common n8n mistake here. A collection job returns a snapshot ID immediately, not data. The workflow then has to poll a progress endpoint until the state reaches ready, handling collecting and digesting as intermediate states and failed as terminal. Workflows built without that loop appear to succeed while producing nothing, because the node returned a job handle and the next step treated it as a result.

Bright Data docs: async requests, snapshots, batch and concurrency limits

Bad input URLs are billed, even though pricing says you pay only for success

Bright Data's marketing is that you only pay for successfully delivered records, and that is broadly true. The qualification is in their documentation: unsuccessful attempts resulting from incorrect inputs by the user will still be billed. A batch containing malformed or dead URLs costs money and returns nothing for those rows. Validating input before submission is not hygiene here, it is cost control.

Bright Data docs: error list by endpoint, 429 handling and billing on bad input

Aggressive retries get your IP blacklisted, not just throttled

Exceeding concurrency returns 429 with the message that you have too many running jobs for this dataset. Bright Data's documented guidance is to stop sending new requests immediately and back off exponentially at two, four, eight, sixteen and thirty two seconds. Critically, an IP receiving 25 or more 429 responses within five minutes faces automatic blacklisting. A naive retry loop in n8n does not just fail, it can get you blocked.

Bright Data docs: error list by endpoint, 429 handling and billing on bad input

Snapshots expire, and the errors are easy to misread

Four distinct failures look similar and mean different things: snapshot is expired, snapshot is empty, snapshot is not ready, and snapshot does not exist. Not ready means keep polling. Empty means the job ran and found nothing, which is usually an input problem. Expired means you waited too long to collect the result. Handling all four as a generic error loses the information that tells you which one you have.

Bright Data docs: error list by endpoint, 429 handling and billing on bad input

LinkedIn person data is profile data, not contact data

The LinkedIn Profiles schema covers name, location, position, about, experience, education, certifications, languages, followers, connections and similar profiles. There is no email field. If the plan is to build an outbound list, this gives you the person and the context but not the address, so it sits alongside an email provider rather than replacing one. Worth knowing before it is designed into a pipeline.

Bright Data docs: LinkedIn scrapers, live scraping and schemas

Confusing the live scraper with the pre-collected dataset

Bright Data sells both, for the same domains, and they behave completely differently. The Scraper API triggers a live scrape with no cached or stale data, priced per record and taking real time to run. Marketplace Datasets are pre-collected, bought in bulk from around $0.0025 per record with a $250 minimum, and refreshed on a schedule. Choosing the wrong one produces either a surprising bill or surprisingly stale data.

Bright Data docs: LinkedIn scrapers, live scraping and schemas

When not to hire anyone

When should you not hire anyone for this?

The node plus an API key covers most of what teams need, and there is nothing to build for straightforward work: pulling company data for a list of domains, enriching accounts with job posting activity, or running a Web Unlocker call against a page that blocks a plain fetch. Where it stops being enough is at scale and around reliability. Polling loops that hold an n8n execution open for minutes do not scale well, the 20 URL batch cap means anything large needs chunking and queueing, retry logic needs to respect the blacklisting threshold rather than hammering, and deciding between live scraping and a bulk dataset purchase is a cost architecture decision rather than a setting.

How we build it

What a Bright Data to n8n build involves

We start by choosing the product, because Bright Data sells five things that people conflate and the wrong choice is expensive. Live Scraper API for freshness, Marketplace Datasets for bulk history, Web Unlocker for one-off blocked pages, Browser API where interaction is genuinely needed, raw proxies only when you are running your own scraper. That decision drives everything downstream.

The async pattern gets built properly rather than approximated. Trigger, persist the snapshot ID, poll on a schedule rather than holding an execution open, and handle collecting, digesting, ready and failed as distinct states. Long jobs come back through a separate workflow rather than blocking the one that started them.

We validate inputs before submission, because bad URLs are billed. Domains are normalised, dead entries are filtered, and batches are chunked to the 20 URL cap with queueing behind it. Retry logic backs off on the documented schedule and stops well short of the blacklisting threshold.

For the workplace sentiment work specifically, which is where Indeed and Glassdoor data earn their place, we treat the output as a signal feeding scoring rather than as fields to dump into a CRM. Company rating and work happiness are interesting as a trend and noisy as a single number, and the pipeline should reflect that.

Two to four weeks for a production collection pipeline, with the range driven by how much queueing and retry infrastructure the volume justifies rather than by the integration itself. See how we scope and price this work.

Sources

Related integrations

Firecrawl to n8n Clay to HubSpot PredictLeads to HubSpot

If you are weighing whether to build this in house or have it built, read what a build like this costs, or see worked examples from real engagements. The vocabulary behind all of this is in the B2B GTM and automation glossary.

Get in touch

Tell us about your situation

Give us some context and we'll come to the conversation prepared. No generic pitch. No obligation.

We review every inquiry personally and respond within one business day.