Skip to main content

Run a real Chrome browser, on our infrastructure, through your proxy.

The Scraping Browser API spins up a remote, fingerprint-hardened Chrome session routed through your NodeMaven proxy, then hands you plain REST endpoints to configure it, drive it, and pull back whatever the page gave you - HTML, a screenshot, a PDF, or the return value of a script you ran on it.
  • api.browser.nodemaven.com - sessions and automation
  • Bearer token - request auth
  • dashboard - where your token lives
  • JSON everywhere

Quickstart flow

Four steps, start to finish - from opening your dashboard to reading back scraped data.
1

Copy your token

Open the Scraping Browser page in the NodeMaven dashboard and copy the API token shown there. Every call below is authenticated with it.dashboard → Scraping Browser
2

Configure and launch

Pick a country/city, stealth options, and proxy protocol, then create a session.POST /sessions
3

Automate it

Navigate, click, type, or run a script - or connect your own Playwright/Selenium/Puppeteer script directly./tools/*, CDP, Selenium
4

Read the results

Pull back the page’s HTML, a screenshot, a PDF, or your script’s return value - then close the session.text · json · png · pdf
This is the whole surface. Everything else in this reference - locations, profiles, page actions - exists to support these four steps: proxy/location endpoints feed step 2, profiles let step 2 remember a setup across sessions, and page actions (click/type/scroll) are the fine-grained half of step 3.

Authentication

One token, one header. Your token is shown in the dashboard - copy it and send it as a Bearer token on every request.

Where to get it

The Scraping Browser page in the NodeMaven dashboard displays your API token. Copy it from there - there’s nothing to generate or exchange.

How to send it

Authorization: Bearer <token> on every Scraping Browser API request. The token is valid for 7 days; when it expires, open the dashboard and copy the current one.
Keep it secret. This token authorizes browser sessions on your account and proxy traffic billed to it. Treat it like a password: keep it server-side, out of client-side code and version control.

Errors and status codes

Every error response is a flat JSON object with a single error string. A few endpoints attach extra machine-readable fields - noted below.

Limits

Defaults below - configurable per account; ask support if your workload needs more.

Proxy and location configuration

Everything a session’s country/region/city/isp/zip fields accept, and a way to check a combination before you spend a session on it.

GET /api/v2/browser/proxy/options

The static vocabulary a session’s proxy targeting understands - connection types, session types, protocols, and the drill-down order for the location endpoints below.
200 Response
Build your IP-filter dropdown from filter_modes rather than hardcoding it - these are the same four modes, in the same order, with the same default as the IP filter mode selector on the main proxy dashboard. filter_levels shows what the quality/speed tokens currently resolve to; those values are platform config, not something a request chooses.

GET /api/v2/browser/locations/{countries|regions|cities|isps|zip-codes}

Drill down through real, currently-available targeting data - the same reference geo-data the main NodeMaven proxy dashboard uses. Filter each level by the one above it. Request:

GET /api/v2/browser/locations/cities?country=us&region=california

200 Response
503 location data not configured for this deployment

POST /api/v2/browser/configurations/validate

Checks a targeting config before you spend a session creating it, and previews the resulting proxy username - using the exact same logic session-create uses, so a config that validates here will create identically.
An invalid config still returns 200 with valid: false and an issues array of {code, field, message, suggestion} - this endpoint reports problems, it doesn’t error on them. A bad filter_mode, for example, comes back as {"code": "unsupported_filter_mode", "field": "filter_mode", ...} with the four valid values in suggestion.
Check valid, not issues.length. When a config is clean, issues is null rather than an empty array - iterating it without a null check will throw.

What each filter mode puts in the proxy username

Use this endpoint to see it for your own config - the preview is generated by the same code that creates sessions, so what you see here is exactly what a session will use.
medium/fast above are the current filter_levels from proxy/options; they’re platform config and can change, so read them from there rather than assuming.

Sessions

A session is one live, disposable Chrome browser, already routed through your proxy. Everything under Automation and results operates on a session’s id.

POST /api/v2/browser/sessions

Launches a browser and returns its connection URL immediately. This is step 3 of the quickstart flow.

GET /api/v2/browser/sessions

Lists your sessions. Filter with ?status=running|ended|all (default all) and cap the page with ?limit=.
200 Response
The list omits cdp_url on purpose - fetch a single session or its connection info when you’re ready to connect to one.

GET /api/v2/browser/sessions/{id}

Full detail on one session, including its cdp_url while it’s still running.
200 Response
config is the resolved targeting the session actually used, with server defaults already applied - so it’s how you confirm after the fact what a session ran with, including which filter_mode was in effect. It never contains your proxy password or the raw proxy username. Location fields are omitted when empty; quality_filter_enabled is the deprecated boolean view of filter_mode (true for the quality-bearing modes).

GET /api/v2/browser/sessions/{id}/connection

Everything needed to connect a script or a browser tab to this session - see Connecting to a session for how each field is used.
200 Response

GET /api/v2/browser/sessions/{id}/pages

Lists the tabs/pages currently open in the session.
200 Response

GET /api/v2/browser/sessions/{id}/recordings

Video replay of the session. Empty while the session is still running - recordings are only published once it ends.
200 Response
video_url is short-lived (~10 minutes) - re-fetch this endpoint at play time rather than caching the URL.

DELETE /api/v2/browser/sessions/{id}

Ends the session immediately. Sessions also auto-end on idle timeout or max lifetime, so this is for when you’re done early.
200 Response
Creating many sessions at once? POST /api/v2/browser/sessions-async queues a create and returns a request_id immediately; poll GET /api/v2/browser/sessions-async/{request_id} for the result. Same fields as the synchronous create above - use it when you’re launching a batch and don’t want to hold a connection open per session.

Profiles

A profile is a saved browser identity - cookies and cache, and optionally a pinned exit IP - that a new session can reattach to instead of starting cold every time.

POST /api/v2/browser/profiles

200 Response
Once a session has used this profile, GET/LIST also return pinned_country, pinned_region, pinned_city, pinned_isp, pinned_zip, pinned_connection_type - where it’s actually pinned to.

GET /api/v2/browser/profiles

Lists every profile on your account. Same shape as a single profile, in a data array.

GET /api/v2/browser/profiles/{id}

Fetches one profile by id.

PATCH /api/v2/browser/profiles/{id}

Renames a profile / updates its description. Body: {"name", "description"}.

DELETE /api/v2/browser/profiles/{id}

Deletes a profile. Sessions already using it are unaffected.

Automation and results

Server-side actions on a running session - no client library required, just POST a JSON body. Every result comes back inline in the response.

POST /api/v2/browser/tools/navigate

Loads a URL in the session’s active page.

POST /api/v2/browser/tools/content

Returns the current page’s full rendered HTML.

POST /api/v2/browser/tools/screenshot

Captures the current page as a PNG.
screenshot is base64-encoded PNG bytes - decode and write to a file, or drop straight into an <img src="data:image/png;base64,...">.

POST /api/v2/browser/tools/execute-code

Runs JavaScript in the page and returns its value - this is “pass automation as a script.”
result is whatever your script returns - a number, string, array, or object - passed through as native JSON.

POST /api/v2/browser/tools/pdf

Renders the current page to a PDF.

POST /api/v2/browser/sessions/{id}/{click|type|scroll}

Fine-grained page actions - the session id is in the path here, not the body, since each hangs off one specific session. All three return {"data": {"status": "ok"}} on success.

Connecting to a session

The /tools/* endpoints cover most automation without any client library. For full control, connect directly using whatever’s already in your stack.

Playwright / Puppeteer

Use cdp_url as-is with connectOverCDP - full CDP control over the exact same browser.

Selenium

Set debugger_address as Chrome’s remote-debugging address - Selenium discovers and attaches automatically.

Live view

Open live_view_url in any browser tab (or embed it in an <iframe>) to watch the session render in real time - handy while developing a script.

Recording playback

Once a session ends, its recordings give you a video replay - useful for auditing what an automated run actually did.

Full walkthrough

Every step above, chained into one script: launch a session in California, load a page, read back the price data, screenshot it, then close it down.

For any questions contact support@nodemaven.com.