Saltar para o conteúdo

API de navegador

Browser API for
JavaScript-heavy pages
and guided interactions.

Browser API is a request-response REST API: load a public page in a hosted browser, wait for the state your workflow needs, execute documented actions, and return a usable output. It does not expose a live browser-control connection.

  • State-aware waits Lifecycle, delay, or selector
  • Guided actions Click, scroll, type, select, submit
  • Contexto da solicitação Device, viewport, country
  • Selectable output HTML, JSON, fields, screenshot

A clearer browser boundary

Reach the rendered state you need without operating browser workers.

Describe the request, readiness condition, interaction sequence, and output. WebScrapingAPI operates the hosted browser execution behind that contract.

01 · render

Handle client-rendered pages

Use browser-backed retrieval when required content appears only after page JavaScript has executed.

Review request controls
02 · synchronize

Capture a deliberate page state

Wait for a lifecycle event, delay, selector, or documented instruction step instead of parsing whatever happens to arrive first.

See the request workflow
03 · deliver

Choose the useful response

Return rendered HTML, a JSON response, a JSON DOM, selected fields, or a screenshot for the downstream task.

Compare output options
Your application definesURL · context · readiness · actions · output
WebScrapingAPI operatesHosted browser execution and response delivery
Your pipeline receivesOne documented response or explicit error

Request anatomy

Configure context, readiness, interaction, and capture in one request.

Start with the target URL and add only the documented controls required to reproduce the page state your application needs. Review exact names and accepted values in the Browser API parameter guide.

01

Contexto da solicitação

Define how the hosted browser reaches and frames the page.

api_key
Server-side authentication
url
URL-encoded public target
method
Target request method
body
Optional target body
country
Supported country context
timeout
Request time budget
device
Desktop, mobile, or tablet
window_width
Viewport width
window_height
Viewport height
block_resources
Optional resource blocking
02

Readiness and actions

Tell the request when the page is ready and what to do next.

wait_until
Lifecycle state
wait_for
Explicit delay
wait_for_css
Required selector
js_instructions
Ordered interaction sequence
auto_solve
Documented access control
clickscrollTotyped_valueselectsubmitclick_and_navigate
03

Capture and response

Select what the browser-backed request should return.

screenshot
Request image capture
screenshot_options
Capture scope and dimensions
extract_rules
Customer-supplied CSS or XPath rules
json_response
JSON response envelope
json_dom
JSON DOM representation
Use the smallest stable recipe.

Prefer an observable selector or lifecycle state over arbitrary delay, keep action sequences short, and validate the returned content against your own business requirements.

Request workflow

Turn page behavior into an explicit request recipe.

The browser runtime is managed by WebScrapingAPI. Your application still defines the intended state and decides whether the returned content is fit for use.

  1. 01

    Define the target

    Provide the URL, method, country, device, viewport, and timeout required for the test case.

    request
  2. 02

    Reach readiness

    Choose domcontentloaded, load, networkidle0, networkidle2, a delay, or a selector.

    state
  3. 03

    Execute actions

    Apply an ordered js_instructions sequence when the page needs clicks, scrolling, values, selections, or navigation.

    interaction
  4. 04

    Return and validate

    Receive the requested format or explicit error, then validate content before it enters the downstream system.

    output
Prefer
Observable readiness

A selector or page lifecycle condition tied to the content you need.

Keep
Instructions minimal

Only the actions required to reach a stable, repeatable state.

Expect
Explicit outcomes

Browser execution can still fail, time out, or return content that needs business validation.

Output contract

Return the representation your next system can use.

Capture the rendered page once, then choose a documented output that fits an existing parser, validation step, evidence record, or media workflow.

01 · default

Plain HTML

Return the rendered page body for a parser or archive process your team operates.

text/html
02 · context

JSON envelope

Wrap the body with documented request and target-response context for inspection.

json_response
03 · document

JSON DOM

Receive the page document as a JSON DOM representation for downstream traversal.

json_dom
04 · selected

Extracted fields

Execute customer-defined CSS or XPath rules and return the selected content.

extract_rules
05 · visual

Screenshot

Capture the full page or a selected element and receive the image as base64.

screenshot
Need the page?
Plain HTML or JSON DOM
Need response context?
JSON envelope
Need named fields?
Extraction rules
Need visual evidence?
Screenshot

Developer integration

Add browser-backed retrieval to the stack you already run.

Call the REST endpoint from your server, keep the API key out of client code, URL-encode request parameters, set a finite timeout, and handle non-success responses deliberately.

Request recipe

Start with one observable state.

These examples wait for main, scroll to it, and request a JSON response. Replace the target, selector, and actions with a sequence validated against your own eligible source.

Endpoint
https://api.webscrapingapi.com/v1
Secret
WSA_API_KEY in server environment
Readiness
wait_for_css=main
Actions
JSON-encode js_instructions
Resposta
Check status before parsing
: "${WSA_API_KEY:?Set WSA_API_KEY}" ACTIONS='[{"action":"scrollTo","selector":"main","timeout":1000,"block":"start"}]' curl --get --fail-with-body --max-time 120 \ "https://api.webscrapingapi.com/v1" \ --data-urlencode "api_key=$WSA_API_KEY" \ --data-urlencode "url=https://example.com/app" \ --data-urlencode "wait_for_css=main" \ --data-urlencode "js_instructions=$ACTIONS" \ --data-urlencode "json_response=1"

The request path is REST. It sends a target and JSON-encoded instructions; it does not open a remote browser-control connection.

Operating ownership

We operate browser execution.
Your team owns the intended state.

A clear boundary makes evaluation more realistic: infrastructure moves behind the API, while source eligibility and business correctness stay with the customer.

WebScrapingAPI

Hosted browser request execution

  • REST request validation and execution
  • Hosted browser runtime with JavaScript rendering
  • Proxy geolocation, IP rotation, and IP block handling
  • Documented waits and instruction execution
  • Requested output generation and response delivery
  • Documented API error response

A sua equipa

Source and data-product decisions

  • Target eligibility, purpose, and request policy
  • Request configuration, interactions, and readiness conditions
  • Selectors, extraction schema, and response validation
  • Source-change maintenance and regression tests
  • Scheduling, storage, retention, and downstream use
Page stateCustomer specifies the state; WebScrapingAPI runs the documented waits and actions.
Browser runtimeWebScrapingAPI operates hosted browser execution and the request infrastructure behind it.
RespostaWebScrapingAPI returns the selected output or error; the customer validates business completeness.
ExtractionWebScrapingAPI executes supplied rules; the customer maintains selectors, schema, and quality checks.

Use Browser API only for eligible public pages. Review source terms, applicable requirements, and the Acordo de serviço, then apply appropriate access, retention, and data-use policies.

Pricing orientation

Evaluate the actual page states
your production workload needs.

Current pricing is the source of truth. A useful evaluation measures representative targets, waits, actions, outputs, errors, and timeouts—not a generic request count alone.

Self-serve evaluation

Prove one stable request recipe.

Start with a representative dynamic page, then validate the smallest combination of context, readiness, actions, and output that meets your requirements.

  • Representative eligible target set
  • Observable readiness condition
  • Shortest required interaction sequence
  • Output and business-validation contract

FAQ

Browser API questions for a grounded evaluation.

Confirm the product boundary first, then use the current documentation for parameter values, action syntax, and error handling.

Read Browser API docs

What is Browser API?

Browser API is a server-side REST request that loads an eligible public webpage in a hosted browser, applies documented waits and actions, and returns the selected response to your application.

When should I use Browser API?

Use Browser API when the target depends on client-side JavaScript, a particular rendered state, or a guided sequence such as clicking, scrolling, typing, selecting, or submitting before capture.

What can Browser API return?

The documented output choices include raw HTML, a JSON envelope, a JSON DOM representation, customer-defined extracted fields, and a screenshot returned as base64 inside the response.

Which page actions are supported?

Documented JavaScript instructions include click, click and navigate, scrolling, typed values, value assignment, selection, submission, focus, and waits. Build and test the shortest sequence that reaches the state you need.

How can a request wait for the right page state?

Use a documented page lifecycle value, a delay, or a CSS selector. You can combine wait_until, wait_for, wait_for_css, and instruction-level waits according to the target behavior.

Can I control device, viewport, and location context?

Yes. Documented controls include desktop, mobile, or tablet device context; window width and height; and supported country-level request context.

Can Browser API capture screenshots?

Yes. Request a screenshot and use documented screenshot options for full-page or selector capture and output dimensions. Screenshot content is returned as base64 in the response.

Does Browser API expose a live browser-control connection?

No. Browser API uses a request-response REST interface. Your application declares supported waits, actions, context, and output through request parameters, then receives the selected response or an API error.

Who owns interaction instructions and extraction rules?

WebScrapingAPI runs hosted browser execution and returns the requested output. Your team owns target eligibility, interaction instructions, selectors, extraction schema, content validation, and source-change maintenance.

How is Browser API different from Scraper API and Managed Data?

Scraper API fits a managed page retrieval with optional rendering. Browser API adds explicit page-state and interaction controls to one REST request. Managed Data moves recurring collection, extraction, quality, and delivery into an operated program.

Your first browser request

Turn one dynamic page into a repeatable request.

Start self-serve, or bring us the target behavior, context, required state, output, and expected request profile for a production review.