01 · Stable entityPilot first
Organization
The candidate company or brand identity that can relate to multiple locations and source listings.
- Normalized name & website
- Organization key
- Relationship evidence
Companies & locations data
Know the business. Preserve every place.
Collect supported public organization and location observations without flattening a brand, branch, listing, and contact point into one unreliable row. Start with documented Google Maps capabilities or scope a maintained multi-source feed.
Entity and place model
Build the relationship before building the row.
A company is not the same object as one location. Stable entities, physical places, source listings, and time-bound observations need separate keys and evidence.
02 · Physical placeDokumentiert
Location
A source-visible place with its own address, coordinates, category, hours, and public contact point.
- Address & coordinates
- Phone, website & hours
- Categories & place status
03 · Source surfaceDokumentiert
Listing, reviews & photos
The directory record and related public observations retained under the source listing identifier.
- Source ID & URL
- Rating aggregate & reviews
- Photo references
Interpretation boundaryNot assumed
One listing does not prove one legal entity.
Names, addresses, domains, and coordinates can be cues, not certainty. Ambiguous parent-child, franchise, duplicate, and moved-location relationships remain explicit.
Coverage states
Distinguish documented access from a scoped data program.
“Business data” is not one source or schema. Verify the source family, discovery input, geography, field presence, and output path that your workflow requires.
QuellenfamilieEingabeTypisches ObjektStaat
Record contract
Keep entity identity, place facts, and observations legible.
Each field should answer what was observed, where it came from, which object it describes, and whether it was absent, unavailable, or awaiting review.
Candidate company identity
- organization_id
- Contracted canonical key when matching is in scope.
- organization_name
- Normalized display name without erasing source names.
- website_domain
- Public domain used as one identity cue.
Physical place
- source_place_id
- Listing or place identifier retained from the source.
- address
- Displayed address plus normalized components where scoped.
- coordinates
- Source-visible latitude and longitude when available.
Time-bound facts
- opening_hours
- Displayed schedule, not a guarantee that the business is open.
- public_contact
- Source-visible business phone or website.
- review_summary
- Displayed rating and count at observation time.
Traceability and state
- source_url
- Public page associated with the observation.
- observed_at
- Timestamp for the collection event.
- collection_state
- Observed, source absent, unavailable, failed, or review.
{
"organization": {
"organization_id": "org_candidate_41",
"name": "Northstar Coffee",
"match_state": "candidate"
},
"location": {
"source_place_id": "demo_place_17",
"city": "Cluj-Napoca",
"category": "Coffee shop",
"phone": "+40 ...",
"hours_state": "displayed"
},
"review_summary": { "rating": 4.6, "count": 328 },
"source": "google_maps",
"observed_at": "YYYY-MM-DDThh:mm:ssZ",
"collection_state": "observed"
}Entity and observation are different layers.
A public listing can describe a place without proving the legal company behind it.
Identity and relationships
Resolve the hierarchy without forcing certainty.
Preserve each source listing first. Add organization and location relationships only through versioned rules and inspectable evidence.
- 01
Source listing
place_id + URL
Retained exactly as observed. - 02
Location cues
Address + coordinates
Name, phone, domain, and category support the comparison. - 03
Relationship state
Exact · candidate · review
Duplicates and ambiguity stay visible. - 04
Canonical layer
Organization ↔ location
Assigned only when included in the contract.
Freshness and history
Let stable identity and changing place facts move at different speeds.
Opening hours, status, reviews, phone, and categories can change independently. The record needs observation time and history semantics, not a generic “fresh” label.
- Requestedrequested_at
The query, geography, locale, and source entered the workflow.
- Observedobserved_at
The public source exposed the recorded location fact.
- Delivereddelivered_at
The record reached the agreed handoff.
- Changedfirst_seen / last_seen
A listing, value, or relationship entered or left history.
Quality and missingness
A missing phone is not a failed location record.
Separate source absence, optional field absence, collection failure, page change, and identity ambiguity so downstream teams can act on the right state.
Place structure present
The requested source listing produced the agreed required fields.
Source or listing changed
A moved, closed, merged, or changed-page cue travels with the record.
Relationship ambiguous
The candidate remains separate until the approved rule resolves it.
No supported observation
Unavailable remains distinct from an empty public field or closed business.
Structural checks
Expected page family, required keys, value types, and schema version.
Field checks
Address components, coordinate shape, category values, review count, and timestamps.
Acceptance boundary
Your team approves source set, required fields, match states, exception thresholds, and downstream interpretation.
Operating model
Choose the operation—not just the output format.
Compare who owns access, extraction, place identity, quality monitoring, source-change maintenance, and delivery.
Maximum infrastructure control
Build your own company-location workflow.
Use proxy infrastructure while your team owns discovery, parsing, entity resolution, quality rules, change handling, storage, and delivery.
VerantwortungOwner
Object, field, and source briefCustomer
Access and collectionShared
Extraction and source schemaCustomer
Identity, quality, maintenance, and deliveryCustomer
Storage, interpretation, and decisionsCustomer
Business applications
Reuse the entity-place foundation without confusing the decisions.
The record supports multiple workflows; each team still owns metrics, thresholds, verification, and the decision made from the observation.
Location intelligence
Map visible business presence, categories, density, and change across a defined geography.
Locations · coordinates · categories · timeSales territory research
Build prospect universes from public business and place observations, then qualify them in your systems.
Organizations · locations · public contactsDirectory monitoring
Track displayed hours, status, phone, website, and listing changes for submitted locations.
Source listings · fields · historyReview intelligence
Analyze public rating and review observations with source and location context preserved.
Review aggregate · review item · placeSite selection inputs
Add public competitor and amenity observations to a wider location-planning model.
Places · categories · geographyMarktforschung und Analyse
Study public business presence and category composition without treating a directory as a company registry.
Source listings · entities · provenanceRepresentative pilot
Test ordinary places and difficult relationships together.
Use target geography, known locations, duplicates, moved or closed listings, missing contacts, multilingual names, and ambiguous organization relationships before scaling.
- 01
Define
Share sources, discovery inputs, geography, objects, fields, cadence, and downstream use.
- 02
Sample
Select ordinary listings plus chains, duplicates, moved places, closed places, and missing fields.
- 03
Inspect
Review source records, organization relationships, timestamps, and exception states.
- 04
Accept
Approve schema, source scope, match rules, thresholds, delivery, and response process.
Evaluation FAQ
Resolve the company-location contract before delivery.
Ten practical answers for data, product, and operations teams evaluating the scope.
What company and location data can WebScrapingAPI provide?
A scoped record can include an organization, one or more physical locations, public contact points, source categories, displayed opening hours, review aggregates, photos, source listing identifiers, URLs, requested context, observation timestamps, and collection states. Available fields depend on the selected public source and page family.
Which business-location capabilities are documented today?
WebScrapingAPI documents a Google Maps API plus Google Maps Reviews and Google Maps Photos capabilities. Generic Scraper API and Browser API access can support other eligible public webpages. Broader firmographic enrichment, multi-source matching, and recurring directory programs begin with a representative pilot.
How are companies and physical locations represented?
The model keeps an organization record separate from each source location record. A location can carry its own address, coordinates, hours, phone, categories, listing identifier, reviews, and observation history, while an organization relationship is added only when the evidence and matching rules support it.
Can the same business be matched across directories?
A scheduled or managed scope can apply agreed matching rules using source identifiers, normalized name, address, phone, domain, coordinates, and category cues. Exact, candidate, ambiguous, unmatched, and source-only states remain explicit. Cross-source matching is not implied for a self-service response.
Can public contact and firmographic fields be enriched?
Public business phone numbers, websites, addresses, categories, hours, and similar fields can be evaluated where they are displayed on an eligible public source. Broad firmographics, contact enrichment, and source-to-source joins are pilot-first because presence, meaning, and reuse conditions differ by source.
How fresh are hours, ratings, and location details?
Request-time products return an observation when the request is processed. Recurring deliveries use an agreed cadence by source and field. Every record should retain observed_at, and a time-sensitive field such as hours should not be treated as current merely because a location identity is stable.
How are closed, moved, duplicate, or missing locations handled?
The contract can distinguish source-reported closure, a moved or merged listing, a suspected duplicate, a temporarily unavailable page, a field not displayed, a collection failure, and an ambiguous match. None of those states is silently converted into an active location or an empty string.
Are reviews and photos part of the same record?
Review aggregates, review-level observations, and photo references can be related to a source listing while remaining separate objects with their own provenance and timestamps. The documented endpoint and representative response determine which review or photo fields are available for a specific request.
Who maintains a recurring company-location feed?
Proxy customers maintain their own collectors and parsers. WebScrapingAPI maintains documented structured endpoints within their product boundary. A scheduled or managed program can place extraction, normalization, quality monitoring, source-change maintenance, and delivery operations with WebScrapingAPI under an agreed contract.
What sources and contact data are outside standard scope?
Private directories, login-only CRM systems, private profiles, and guaranteed personal contact data are not standard scope. Collection is limited to eligible public webpages and agreed public fields, and customers remain responsible for lawful use, retention, access controls, and decisions made with the data.
Companies & locations data
Start with a documented lookup or a representative record set.
Use self-serve access for your own workflow, or bring the sources, geography, objects, and fields you need to a data expert.