brightdata-sdk

Original：🇺🇸 English

Translated

Bright Data's Python and Node.js SDKs for calling Web Scraper API, SERP, Web Unlocker and Scraper Studio from application code. Use when the user is writing code they keep that calls Bright Data on a schedule or inside a pipeline, when the same job runs again and again, when a Bright Data package is imported in Python or Node.js, when the user wants their own API or service built on top of Bright Data ("build me a scraper API", "wrap this in an endpoint"), or when the user names the SDK. Not for one-off checks typed at a shell, which belong to brightdata-cli. Not for an AI app that chooses its tools at run time, which belongs to brightdata-mcp. Not for install, login or API key problems, which belong to agent-onboarding.

3installs

Sourcebrightdata/skills

Added on2026-11-08

NPX Install

npx skill4agent add brightdata/skills brightdata-sdk

SKILL.md Content

View Translation Comparison →

Bright Data SDKs

Two published packages, one skill. The request is the same in both languages, so follow the language the repo already uses.

Language	Package	Registry	Install
Python	`brightdata-sdk`	PyPI	`pip install brightdata-sdk`
Node.js	`@brightdata/sdk`	npm	`npm install @brightdata/sdk`

Which reference to open

A

pyproject.toml

, a

requirements.txt

or

.py

files are in the project: open

references/python.md

.

A

package.json

or

.js

,

.mjs

and

.ts

files are in the project: open

references/nodejs.md

.

Both languages are present and neither clearly owns the job: ask which runtime will run it, then open that one file.

When the SDK is the right surface

The user keeps the code. A cron job, a backend service, an ETL step, an enrichment pipeline: anything where the same call runs again and again from a file under version control. Reach for the SDK the moment a Bright Data call is going to live in a repo rather than in a terminal.

Two neighbours own the other cases. A one-off check typed at a shell is

brightdata-cli

. An AI app that picks its tools at run time is

brightdata-mcp

.

Auth

Install, login and API key problems belong to

agent-onboarding

, which owns credential paths and what a refused call means. See its

references/auth.md

.

The one fact this skill needs: both SDKs read

BRIGHTDATA_API_TOKEN

first, accept

BRIGHTDATA_API_KEY

as an alternate, and fall back to the credentials the Bright Data CLI stored at login. Never write a key into source. Both reference files show the key coming from the environment. To check that a key exists, run

node scripts/check-auth.mjs

from the

agent-onboarding

skill; never

cat

,

echo

or

jq

the credentials file or the variable, because whatever a command prints lands in the conversation and its logs.

What both packages cover

Page fetch, SERP search, per-platform scrapers, a crawler, dataset access, Browser API connect strings, and a Scraper Studio namespace. The shape differs by language: Python is async first and uses snake_case, Node.js uses camelCase and has to be closed, either with

close()

by hand or with

await using

on modern runtimes. Read the reference file rather than translating method names by hand.

By default both SDKs create the zones

sdk_unlocker

and

sdk_serp

in the account when they are missing: Python when the client opens, Node on the first call that uses each zone. Tell the user before running code that will do that. Each reference file shows how to turn auto-creation off and use the account's own zones.