BG Rentals Properties and Details Scraper

This Actor extracts bounded rental-listing fields from imot.bg, one of Bulgaria's real-estate listing sites. It reads the site's Windows-1251 listing HTML, follows rental pagination, and can enrich listing fields from a public detail page when you already have applicable data-reuse authorization.

The Actor returns one normalized listing record per unique advertisement. Records can include the listing ID and URL, title, property type, location, rent and currency, area, floor, advertised features, listing status, images, description, views, and update text when the source supplies them. New records omit personal contact details, seller identity, and raw page text. Only records with an official listing URL, identity, title, and at least one property-specific fact enter the dataset. Diagnostics and failure details are kept in the OUTPUT key-value summary. The dataset schema includes an optional browserVerification object for dated, manually checked public-page observations; it does not change the historical Actor scrapedAt value.

Input

The checked-in ./INPUT.json is a small local verification input. The main input fields are:

• start_urls: HTTPS imot.bg rental collection, city/region, pagination, or detail URLs.
• max_items: maximum unique listing records across all sources.
• max_list_pages_per_source: bounded public pagination per source.
• max_detail_pages and include_details: detail-page enrichment controls.
• data_use_authorized: default-false operator attestation that you already hold applicable rights to collect and reuse the requested data.
• request_delay_ms and request_timeout_seconds: polite request and timeout controls.

The default input uses https://www.imot.bg/obiavi/naemi, but makes zero source requests because data_use_authorized defaults to false. Set it to true only if you already hold applicable permission; the checkbox is an operator attestation and does not grant permission. The crawler deduplicates by the stable advertisement ID and does not collect seller contact information, submit contact forms, log in, call private endpoints, fetch image/CDN resources, or use a proxy.

Local development

npm test
npm run lint
apify validate-schema
npm run validate:storage

Do not use --purge for local checks: it deletes saved Actor storage. The saved datasets are historical snapshots, and the current browser comparison is documented separately in ./BROWSER_REVIEW.md.

The implementation is split into configuration/input normalization, an HTTPS transport with redirect validation, HTML/JSON-LD parsing, record shaping, crawling, run-status classification, and the Apify lifecycle entrypoint. OUTPUT stores a bounded run summary and diagnostic details; the dataset contains normalized listing records only.

Run summaries use SUCCEEDED / COMPLETED for clean bounded or empty results, SUCCEEDED / PARTIAL when at least one listing is saved before a later failure, and FAILED / FAILED when failures leave no saved listing. The native exit code is 0 for successful and partial runs, and 1 for failures with no saved listings.

Source access and data use

The General Terms page was reviewed in Chrome on 2026-09-30. The visible text contained no explicit automated-collection restriction, but this review did not find a specific data-reuse license. Public visibility is not permission for bulk reuse, so the Actor skips by default. Only HTTPS pages on imot.bg and www.imot.bg are accepted, and redirect destinations are validated against the same allowlist. The Actor does not bypass authentication, paywalls, CAPTCHAs, rate limits, or other access controls.

Access boundary

This review sampled only public rendered pages. It did not submit contact forms, log in, open contact-information controls, or store personal contact details. New runs omit phone numbers, seller names, and raw page text. Historical local snapshots are preserved as historical data and can contain legacy fields that the current runtime no longer emits.

Dependency security and HTTP caching

The locked dependencies require Node.js 20.18.1 or later. Implemented Actor Cloud builds use Node.js 22.

HTTP response caching is disabled throughout the SDK dependency graph by a project-owned, tested non-caching policy replacement. Responses are always fetched afresh; stale cached responses and serialized cache headers cannot be reused. This replaces the vulnerable package rather than suppressing its advisory. The locked FTP client is 6.2.1; the SDK keeps its supported interface.

The original unpatched-cache advisory is GHSA-ch52-4w7c-c8xp. The FTP patch is documented in GHSA-c475-qrg2-pj4r. Project tests include actual localhost HTTP requests with a shared cache and distinct user headers. These tests make no target-site requests and do not qualify extraction.