Stable entity
Product identity
Brand, model, canonical title, categories, identifiers, descriptions, attributes, and media.
- ASIN / SKU / GTIN / MPN
- Brand & model
- Category & attributes
Produkte, Preise & Bewertungen
Commerce data built around the record, not the scrape.
Collect supported public product, variant, offer, seller, rating, and review observations through documented commerce APIs, or receive a maintained dataset shaped around your sources, fields, context, and cadence.
Commerce record model
A product page is not one object.
Separate identity from the observations that change by seller, location, page, and time. The result is easier to compare, update, and govern.
Configuration
Variant
Size, color, capacity, unit, pack, style, or another source-defined configuration of a product.
- Variant identifier
- Option labels
- Parent relationship
Time-bound observation
Offer
Displayed price, list price, promotion, condition, availability, shipping, pickup, and fulfillment context.
- Value & currency
- Seller & condition
- Observed context
Marketplace entity
Seller
Public merchant identity and storefront context kept separate from the product and offer it supplies.
- Seller ID & name
- Storefront URL
- Public rating context
Public feedback
Review
Aggregate ratings, distributions, counts, and review-level fields where the selected endpoint or scope supports them.
- Rating & count
- Review text & date
- Source-level availability
Quellenabdeckung
Know what is documented. Pilot what is source-specific.
A source logo is not a field guarantee. Evaluate the endpoint, page type, request inputs, response fields, and missing states that matter to your workflow.
Dokumentiert
Structured commerce endpoints
Current documentation lists marketplace and retailer APIs with source-specific request and response contracts.
- Amazon
- eBay
- Walmart
- Best Buy
- Home Depot
- Lowe's
- Nordstrom
- Target
- Wayfair
Pilot first
Additional eligible public commerce sources
Retailer, marketplace, brand, comparison, and review sources are evaluated with representative pages before a recurring commitment.
- Required page families and discovery inputs
- Country, postal, language, and device context
- Field presence, optional modules, and failure states
- Cadence, volume, retention, and delivery fit
Nicht standardmäßig
Private or transactional customer surfaces
Private account, cart, checkout, or customer data is outside the standard public-web scope.
- Authenticated customer accounts
- Orders and transaction records
- Personalized checkout totals
- Internal retailer inventory systems
Field contract
Inspect the record before choosing the delivery path.
Start from the fields your system needs, then map source values, optional modules, identifiers, and quality states into a documented schema.
Identity
product_id · source_product_id · brand · title · category · attributes · media
Variant
variant_id · parent_id · size · color · unit · pack_quantity · option_labels
Offer & price
current_price · list_price · currency · promotion · condition · seller_id
Availability & fulfillment
availability_text · normalized_state · shipping · pickup · delivery_window
Ratings & reviews
rating · rating_count · review_count · distribution · review_items
Provenance & quality
source_url · observed_at · requested_context · collection_state · schema_version
{
"record_id": "obs_001",
"schema_version": "commerce.v1",
"product": {
"source_product_id": "DEMO-128",
"brand": "Example",
"title": "Wireless headphones",
"variant": { "color": "black" }
},
"offer": {
"current_price": 79.00,
"list_price": 99.00,
"currency": "USD",
"availability_text": "In stock"
},
"rating": {
"value": 4.6,
"count": 1248
},
"source_url": "https://retailer.example/p/001",
"observed_at": "YYYY-MM-DDThh:mm:ssZ",
"collection_state": "observed"
}A displayed price is an observation, not a checkout total. Displayed availability is not an inventory guarantee.
Identity & matching
Normalize without erasing the source.
Keep the original observation, then add a contracted identity layer only where the comparison is explainable and testable.
- 01Exact identifiers firstASIN, GTIN, MPN, SKU, or customer reference where available
- 02Normalize comparison fieldsBrand, model, title, unit, pack, attributes, and variant
- 03Apply approved rulesThresholds, exclusions, reason codes, and schema version
ResultCandidate matchExact brand + model · variant cue missing
Freshness & history
Freshness is a field contract, not a badge.
Specify when collection should run, what timestamp a record carries, and which changes need to become history rather than overwritten values.
Request-time
Call a documented endpoint.
The response represents the supported page and requested context when the request is processed.Asynchronous
Submit work, then retrieve a snapshot.
Selected retailer endpoints return a snapshot identifier while structured records are prepared.Scheduled
Refresh an agreed source set.
Cadence can differ by source, page family, product tier, and field volatility.Longitudinal
Retain observations and change events.
History begins with collection unless a separate historical source is validated.Quality & missingness
Make every non-value explain itself.
Quality is not one accuracy percentage. It is a set of agreed checks and observable states attached to the field, record, source, and delivery.
StaatBedeutungDownstream-Maßnahme
The supported field or object was returned in the requested context.
Use with timestamp and sourceThe page was collected, but the selected module or field was not displayed.
Keep distinct from zeroThe page or object was not available in the requested public context.
Do not infer inventoryThe collection event did not produce a usable page or supported response.
Retry or escalate by contractA value did not meet the agreed structure, type, or parsing rule.
Quarantine with reasonIdentity cues were incomplete, conflicting, or below the agreed threshold.
Keep source record availableOperating model
Choose the commerce-data handoff your team needs.
Compare all four paths against the same lifecycle. Every panel remains readable without JavaScript.
Maximum stack control
Run your commerce collectors on proxy infrastructure.
Your team chooses sources, builds the crawler and parser, models product objects, schedules collection, monitors quality, and delivers records. WebScrapingAPI operates the contracted proxy access layer.
VerantwortungOwner
Sources, markets, object model, and acceptance rulesCustomer
Network access and proxy operationWSA
Collection, rendering, and extractionCustomer
Identity, normalization, history, and qualityCustomer
Scheduling, maintenance, delivery, and decisionsCustomer
Best fit · Teams with established commerce-data engineering and a requirement to control collection and schema logic.
Explore proxy infrastructureAcross every model, the customer retains pricing, merchandising, enforcement, and downstream decisions. WebScrapingAPI supplies access, structured observations, or operated delivery according to the selected product and contract.
What teams build
One record model. Six different workflows.
The same source-linked objects can support multiple teams without pretending that the collected observation makes the business decision.
Representative pilot
Evaluate records, states, and ownership before scale.
A useful pilot proves the hardest source and field combinations, not only the cleanest product pages.
- 01
Brief
Name the objects and contexts.
Sources, page types, identifiers, markets, locations, devices, fields, cadence, and exclusions. - 02
Sample
Collect representative pages.
Include variants, promotions, multiple sellers, missing modules, unavailable pages, and review differences. - 03
Contract
Approve schema and quality states.
Field definitions, source mapping, matching rules, reason codes, history, acceptance, and delivery format. - 04
Handoff
Choose the operating model.
Use the validated scope to assign access, extraction, maintenance, quality, delivery, and decision ownership.
Evaluation FAQ
Questions to settle before collection begins.
These answers define the product and responsibility boundaries buyers should evaluate. The disclosures remain available without JavaScript.
What product and commerce data can WebScrapingAPI provide?
Depending on the documented endpoint or agreed source scope, records can include product identifiers, titles, brands, categories, attributes, variants, images, displayed prices, promotions, sellers, visible availability, fulfillment details, ratings, review counts, review content, source context, timestamps, and collection states.
Which commerce sources are documented today?
WebScrapingAPI documentation currently lists structured marketplace APIs for Amazon, eBay, and Walmart, plus retailer APIs for Best Buy, Home Depot, Lowe's, Nordstrom, Target, and Wayfair. Supported page types, inputs, fields, and response patterns differ by endpoint, so the relevant documentation and a representative request define the usable scope.
Can reviews and ratings be delivered?
Ratings, review counts, rating distributions, or review excerpts are documented for selected product endpoints and can also be evaluated in a scoped data program. Review fields vary by source and page type, and a rating summary should not be presented as complete review coverage unless that coverage is verified.
How do product, variant, offer, seller, and review records relate?
The data model keeps stable product identity separate from source variants, time-bound offers, seller context, and review observations. Every object can retain its source URL, source identifier, requested context, observation time, and collection state so downstream teams can join records without erasing where they came from.
Can the same product be matched across sources?
A scheduled or managed scope can include matching rules based on exact identifiers first, followed by agreed brand, model, title, attribute, unit, pack, and variant checks. Ambiguous and unmatched observations remain explicit. Matching is not implied for every self-service API response.
How fresh can product and price data be?
Documented APIs return an observation when a request or asynchronous job is processed. Scheduled and managed deliveries use an agreed refresh window by source, page type, field, and business need. Every record should retain an observed-at timestamp rather than relying on a generic freshness claim.
Can historical price, seller, and availability changes be delivered?
A recurring contracted delivery can retain successive observations and derived change events for selected fields. History normally begins when collection begins unless a separate historical source is validated, and a page becoming unavailable remains distinct from a product being shown as unavailable.
How are missing fields and failed collections represented?
The record contract can distinguish a field not shown by the source, a page or object unavailable in the requested context, a collection failure, a parsing or schema exception, and a match that needs review. These states should never be collapsed into zero, false, or an empty string without an explicit rule.
Who maintains collection when a commerce page changes?
Proxy customers maintain their collectors, parsers, and downstream quality rules. WebScrapingAPI maintains documented structured endpoints within the product boundary. Scheduled datasets and managed programs can include contracted extraction, normalization, quality monitoring, source-change maintenance, and delivery operations.
What responsible-use and data boundaries apply?
The scope is limited to eligible public webpages and agreed public fields. Private account, cart, checkout, order, and customer data are not standard scope. Customers remain responsible for lawful use, retention, access controls, and pricing, merchandising, enforcement, or other decisions made with the delivered data.
Produkte, Preise & Bewertungen
Start with one endpoint or one representative data brief.
Use a documented commerce API in your own workflow, or show us the sources, fields, context, and refresh window your team needs delivered.