抓取 API
For direct page retrieval through an operated access path.
Use when
You have URLs and want the API to handle routing, access handling, optional rendering, and response delivery.
Typical outputPage responseView product
- 5 access pathsPages, search, browser tasks, crawls, and records
- 管理检索WebScrapingAPI operates the access path behind each API
- Clear output choicesHTML, rendered output, SERPs, page sets, or structured records
- Composable stackUse one API or combine them by workflow stage
Compare APIs
Start with what your application sends and what it needs back.
Each Web Access API reduces a different part of the scraping workload. The right choice depends on whether the unit of work is a URL, query, browser interaction, source scope, or supported target record.
SERP API
For search result collection by engine and market context.
Use when
You need search results from supported engines with query, location, language, device, and result context.
Typical outputStructured SERP dataView product
浏览器 API
For browser-backed page access through a server-side REST request.
Use when
The page needs rendering, waits, documented interactions, navigation steps, screenshots, or output controls.
Typical outputRendered page outputView product
爬取 API
For bounded multi-page collection from a defined source scope.
Use when
You need a coordinated collection of related eligible public pages instead of one page at a time.
Typical outputCollected page setView product
数据 API
For source-specific structured records from supported targets.
Use when
You want product, search, AI, commerce, travel, social, business, or marketplace records without building source-specific parsing.
Typical outputStructured recordsView product
Side-by-side view
Compare the operating boundary, not a checklist of overlapping features.
Start with the input you already have, then choose the smallest output your next system can use.
API | Starting input | Primary output | WebScrapingAPI operates | Your application owns |
|---|---|---|---|---|
Known URL + documented request options | Page body, JSON envelope, or selected fields | Routing, access handling, optional rendering, and internal target retries | Target choice, request policy, downstream validation, parsing, and storage | |
Engine, query, and supported search context | Engine-specific parsed collections or source SERP payload | Supported search retrieval and the documented engine response path | Query plan, observation schedule, result interpretation, and storage | |
URL, readiness condition, supported actions, and output | HTML, JSON, selected fields, or screenshot | Hosted browser execution and request infrastructure | Interaction recipe, extraction schema, validation, and downstream use | |
Approved entry point, source boundary, and collection criteria | Bounded collection of related page results | The scoped multi-page collection workflow | Scope requirements, result criteria, quality review, and destination | |
Supported source, record type, and available parameters | Maintained structured source record | Source access, extraction, parser maintenance, and quality monitoring | Record selection, business validation, storage, and decisions |
Choose by job
Map the request to the API before you evaluate volume.
The strongest evaluation starts with the smallest real workload that proves the interface, output, and ownership model.
Known URL
Retrieve one page
Choose Scraper API for a URL-to-response workflow through managed access.Scraper APISearch query + contextObserve a search result set
Choose SERP API when engine, query, location, language, device, and result context define the answer.SERP APIURL + page stateRender and interact
Choose Browser API when readiness, supported actions, screenshots, or rendered output are part of the request.Browser APIStarting scopeCollect related pages
Choose Crawl API when the unit of work is a bounded set of eligible pages rather than one URL.Crawl APISupported source + recordReceive maintained fields
Choose Data API when a supported source-specific record can move structured data directly into your application.Data APIWorkflow design
Compose APIs when the workflow crosses product boundaries.
Your application calls each product directly and passes selected results to the next stage. The APIs do not automatically route work between themselves.
01
Discover
Find targets with SERP API, source lists, or your own application logic.
02
Retrieve
Fetch known pages with Scraper API or Browser API, depending on rendering and interaction needs.
03
Expand
Use Crawl API for bounded related-page collection when the source scope is larger than one URL.
04
Structure
Use Data API for supported source records, or parse page output inside your own pipeline.
Example: SERP API can return result URLs; your application selects the relevant URLs, then calls Scraper API or Browser API for the chosen pages.
Operating boundary
Know what the platform runs—and what stays in your application.
The exact boundary changes by product, but orchestration, business validation, and downstream decisions remain visible.
WebScrapingAPI operates
The product-specific access path
- Routing and access infrastructure behind the selected API
- Supported search retrieval, hosted browser execution, or scoped crawl operation where applicable
- Source-specific extraction, parser maintenance, and quality monitoring for supported Data API records
- The documented response, result, and error boundary for the selected product
Your application owns
The workload, orchestration, and decisions
- Eligible sources, collection purpose, and request inputs
- Which API to call and how results move between products
- Business-schema checks, downstream storage, and retention
- Alerts, analytics, models, and decisions built from the returned data
Integration
Five products. A familiar server-side integration boundary.
Call the selected API from any server-side stack that can make HTTPS requests and handle its documented response. Use the individual product guide for current parameters, response shapes, and error handling.
01 · your stackHTTP clientRequest inputs + context
02 · selected productWeb Access APIProduct-specific operation
03 · your pipelineResponse consumerValidate + store + use
cURLJavaScriptPythonPHPJavaC#GoRuby
These are standard HTTPS integration paths, not a claim that every product has a dedicated SDK for every language.
APIs vs proxies
Use APIs when you want WSA to run more of the access path.
Use proxies when your collector should control the full request workflow. Use Web Access APIs when your application should send a higher-level request and consume a cleaner response or record.
Choose APIs
You want request-time access handled through product-specific endpoints.
You need search, browser, crawl, or source-specific structured output.
You want less infrastructure and access logic in your own collector.
Choose proxies
You operate the client, crawler, browser, parsing, and retry strategy.
You need direct control over connection behavior and collector design.
You want to choose Residential, Datacenter, or ISP routes under your stack.
FAQ
Questions buyers ask before choosing an API.
Use the unit of work, output contract, and operating boundary to narrow the first evaluation path.
Which web access API should I start with?
Start with the unit of work: Scraper API for one known page, SERP API for a search result set, Browser API for a rendered or interactive page state, Crawl API for a bounded collection of related pages, and Data API for a supported structured source record.
What is the difference between Scraper API and Browser API?
Scraper API is the simpler starting point for a URL-to-response request and can optionally render JavaScript. Browser API is designed for a page that needs an explicit readiness condition, supported browser actions, or a rendered-state capture before your application receives the result.
What is the difference between Scraper API and Crawl API?
Scraper API handles one page request at a time. Crawl API is evaluated for a bounded collection whose unit of work spans related eligible pages, starting from an approved source scope and collection criteria.
When should I choose Data API?
Choose Data API when the source and record type are supported and your application needs maintained structured fields. WebScrapingAPI operates source access, extraction, parser maintenance, and quality monitoring for that supported record path.
Is SERP API only for search results?
Yes. SERP API is the specialist product for documented search-engine requests and engine-specific outputs. Use another web access API for a general webpage, browser interaction, bounded crawl, or supported source-specific record.
Can one workflow use more than one web access API?
Yes. Your application can call more than one API when a workflow crosses product boundaries, such as discovering result URLs with SERP API and retrieving selected pages with Scraper API or Browser API. Your application owns that orchestration.
When should I use web access APIs instead of proxies?
Use web access APIs when you want WebScrapingAPI to operate the product-specific access path behind a request or collection job. Use proxies when your own HTTP client, crawler, or browser should control requests, retries, parsing, and collection logic directly.
Who owns extraction and data quality?
Ownership depends on the product. With Data API, WebScrapingAPI operates extraction, parser maintenance, and quality monitoring for supported records. With page-access products, your team generally owns downstream parsing, business-schema validation, storage, and decisions.
How should I evaluate the APIs?
Use representative sources and define the required context, usable output, volume, freshness, and downstream destination. Compare the smallest API boundary that delivers the result your application can validate and operate.
Choose the API
Bring one real workload and compare the access path.
Share the source, request shape, output target, volume, freshness, and ownership boundary. We will map it to the right Web Access API or recommend proxies, feeds, or managed delivery when they fit better.