Bing Maps Business Listings Scraper

Searches public Bing Maps business listings and writes a rich normalized dataset. The Actor uses Bing's public maps/overlaybfpr HTML endpoint first because it exposes structured data-entity business payloads. When that endpoint returns no usable records, the Actor can open Bing Maps with Playwright and extract the same payload from the DOM.

Input modes

Use one query for a normal search, or provide searchQueries for a batch. If both are supplied, query is included as the first query and duplicate phrases are removed. Batch results are collected independently, capped per query, and interleaved fairly before the global maxItems limit is applied.

For compatibility with existing Cloud inputs, the Actor also accepts maxRetries, requestTimeoutMs, and categoryIncludes. The first two take precedence over maxRequestRetries and requestTimeoutSecs when both forms are supplied; categoryIncludes is combined with includeCategories.

Example single-query input:

{
  "query": "restaurants in Austin",
  "maxItems": 25,
  "maxPages": 2,
  "resultsPerPage": 10,
  "sortBy": "ratingDesc",
  "proxyConfiguration": { "useApifyProxy": false }
}

Example multi-query input:

{
  "searchQueries": ["coffee shops in Austin", "bookstores in Austin"],
  "maxItems": 20,
  "maxItemsPerQuery": 10,
  "maxPages": 2,
  "resultsPerPage": 10,
  "maxConcurrency": 1,
  "maxRequestRetries": 1,
  "requestTimeoutSecs": 45,
  "requestHandlerTimeoutSecs": 180,
  "requestDelayMs": 500,
  "includeKeywords": ["Austin"],
  "excludeCategories": ["closed"],
  "sortBy": "searchOrder",
  "proxyConfiguration": { "useApifyProxy": false }
}

The complete input schema is in .actor/input_schema.json. Fields and defaults:

Field	Type	Default
query	string	—
searchQueries	array of strings	[]
market	string	en-US
language	string	en-US
countryCode	string	US
maxItems	integer	50
maxItemsPerQuery	integer	50
maxPages	integer	5
resultsPerPage	integer	25
includeKeywords	array of strings	[]
excludeKeywords	array of strings	[]
includeCategories	array of strings	[]
categoryIncludes	string	—
excludeCategories	array of strings	[]
minRating	number	—
minReviewCount	integer	—
openNowOnly	boolean	false
requireWebsite	boolean	false
requirePhone	boolean	false
includePermanentlyClosed	boolean	false
sortBy	string	searchOrder
maxConcurrency	integer	1
maxRequestRetries	integer	1
maxRetries	integer	—
requestTimeoutSecs	integer	45
requestTimeoutMs	integer	—
requestHandlerTimeoutSecs	integer	180
navigationTimeoutSecs	integer	45
requestDelayMs	integer	500
blockMedia	boolean	true
headless	boolean	true
fallbackToDom	boolean	true
proxyConfiguration	object	—

Output

Each dataset record has a stable Bing place ID and can include the listing name, address parts, coordinates, phone, website, category path, rating provider, rating and review counts, open status, hours, media, map/detail links, page and query positions, and source provenance. Numeric values are normalized to numbers and dates are ISO-8601 strings. The dataset has overview and fullDetails views.

The complete output schema, including field types and requiredness, is in .actor/dataset_schema.json.

The final selected records are then enriched from Bing's own single-entity detail panel (maps/overlaybfpr scoped with local_ypid and cardType=details), which adds the About description, the Details/amenities list, the first recent review snippet, the claimed-listing flag, and the Directions link. Enrichment is bounded (detailsRequested, detailsFetched, detailsFailed, detailsSkipped) and additive: a failed detail request keeps the list-level record.

samples/sample-record.json is the first record from a live run for restaurants in Austin. Its business name, address, category, rating, review count, and hours were checked against the corresponding Bing Maps search listing.

The OUTPUT key-value record contains run status, per-query page/card counts, filters, sorting, failure categories, connection mode, detail-enrichment counts, and whether the DOM fallback was used. Result-count text is retained when Bing exposes it in the structured response.

If any structured or DOM-fallback query/page attempt fails, the Apify run reports failure even when other attempts returned valid listings. Those valid business records remain in the dataset, and OUTPUT.status is failed; a confirmed search with no matching listings remains no-results.

Proxy and access behavior

The input supports no proxy, Apify Proxy, and custom proxy URLs. Proxy credentials are consumed by the runtime and are never written to the dataset or logs. HTTP status and content type are checked before the response is parsed. Access-control, CAPTCHA, login, and verification pages are reported as failures; the Actor does not bypass them.

How to use

Enter a place query or batch in the Apify Input tab, select search filters, and start the Actor. Inspect place records in the Output dataset and run metrics in the OUTPUT key-value record.