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 Browser2
Configure and launch
Pick a country/city, stealth options, and proxy protocol, then create a session.
POST /sessions3
Automate it
Navigate, click, type, or run a script - or connect your own Playwright/Selenium/Puppeteer script directly.
/tools/*, CDP, Selenium4
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 · pdfThis 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.Errors and status codes
Every error response is a flat JSON object with a singleerror 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’scountry/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®ion=california
200 Response
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.
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.
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’sid.
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
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
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
Usecdp_url as-is with connectOverCDP - full CDP control over the exact same browser.
Selenium
Setdebugger_address as Chrome’s remote-debugging address - Selenium discovers and attaches automatically.
Live view
Openlive_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.